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Abstract. We present a calculus that models a form of process interaction based on 
copyless message passing, in the style of Singularity OS. The calculus is equipped with a 
type system ensuring that well- typed processes are free from memory faults, memory leaks, 
and communication errors. The type system is essentially linear, but we show that linearity 
alone is inadequate, because it leaves room for scenarios where well-typed processes leak 
significant amounts of memory. We address these problems basing the type system upon 
an original variant of session types. 



1. Introduction 

Communicating systems pervade every modern computing environment ranging from light- 
weight threads in multi-core architectures to Web services deployed over wide area networks. 
Message passing is a widespread communication paradigm adopted in many such systems. 
In this paradigm, it is usually the case that a message traveling on a channel is copied 
from the source to the destination. This is inevitable in a distributed setting, where the 
communicating parties are loosely coupled, but some small-scale systems grant access to 
a shared address space. In these cases it is possible to conceive a different communica- 
tion paradigm - copyless message passing - where only pointers to messages are copied 
from the source to the destination. The Singularity Operating System (Singularity OS for 
short) [151 [16] is a notable example of system that adopts the copyless paradigm. In Sin- 
gularity OS, processes have access to their own local memory as well as to a region called 
exchange heap that is shared by all processes in the system and that is explicitly managed 
(objects on the exchange heap are not garbage collected, but are explicitly allocated and 
deallocated by processes). Inter-process communication solely occurs by means of message 
passing over channels allocated on the exchange heap and messages are themselves pointers 
to the exchange heap. 

The copyless paradigm has obvious performance advantages, because it may dramat- 
ically decrease the overhead caused by copying (possibly large) messages. At the same 
time, it fosters the proliferation of subtle programming errors due to the explicit handling 
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of pointers and the sharing of data. For this reason, Singularity processes must respect an 
ownership invariant: at any given point in time, each object allocated on the exchange heap 
is owned by exactly one process. In addition, inter-process communication is regulated by 
so-called channel contracts which specify, for each channel, the sequences of interactions 
that are expected to occur. Overall, these features are meant to prevent memory faults 
(the access to non-owned/deallocated/uninitialized objects on the exchange heap), memory 
leaks (the accumulation of unreachable allocated objects on the exchange heap), and com- 
munication errors which could cause the abnormal termination of processes and trigger the 
previous kinds of errors. 

In this paper we attempt at providing a formal foundation to the copyless paradigm 
from a type-theoretic point of view, along the following lines: 

• We develop a process calculus that captures the essential features of Singularity OS 
and formalizes a substantial fragment of Sing*, the programming language specifically 
designed for the development of programs that run in Singularity OS. We provide a formal 
characterization of well-behaved systems, those that are free from memory faults, memory 
leaks, and communication errors. 

• We develop a type system ensuring that well-typed systems are well behaved. The type 
system is fundamentally based on the linear usage of pointers and on endpoint types, a 
variant of session types [1'6\ [T^l 122] tailored to the communication model of Singularity 
OS. We provide evidence that session types are a natural and expressive formalization of 
channel contracts. 

• We show that the combination of linearity and endpoint types is insufficient for preserv- 
ing the ownership invariant, but also that endpoint types convey enough information 
to tighten the type system so as to guarantee its soundness. This allows us to give an 
indirect soundness proof of the current Singularity OS implementation. 

The rest of the paper is organized as follows. In Section[2jwe take a quick tour of Sing* and 
we focus on its peculiar features in the context of Singularity OS that we are going to study 
more formally in the subsequent sections. In Section E] we define syntax and semantics (in 
terms of subtyping) of the type language for our type system. We also give a number of 
examples showing how to represent the Sing* types and channel contracts encountered in 
Section [5] into our type language. Section [H presents the syntax and reduction semantics 
of the process calculus and ends with the formal definition of well-behaved systems. Since 
we want to model the copyless paradigm, our calculus includes an explicit representation of 
the exchange heap and of the objects allocated therein. Names in the language represent 
pointers to the exchange heap rather than abstract communication channels. Section E] 
begins showing that a traditionally conceived type system based on linearity and behavioral 
types may leave room for violations of the ownership invariant. We then devise a type- 
theoretic approach to solve the problem, we present the type rules for the exchange heap 
and the process calculus and the soundness results of the type system. In Section[6]we define 
algorithms for deciding the subtyping relation and for implementing the type checking 
rules presented in the previous section. We relate our work with relevant literature in 
Section [7J where we also detail similarities and differences between this paper and two 
earlier versions [2j E] that have appeared in conference and workshop proceedings. We 
conclude in Section [8] with a summary of our work. For the sake of readability, proofs 
and additional technical material relative to Sections El El and El have been moved into 
Appendixes [Al [Bl and [O respectively. 
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void map<a,/3>(imp<Mapper<a,/3>:WAIT_ARG> in ExHeap mapper, 

[Claims] imp<Stream<a> : START> in ExHeap source, 
[Claims] exp<Stream</3> : START> in ExHeap target) { 
switch receive { 

case source. Data(a in ExHeap x) : 
mapper. Arg(x) ; 
switch receive { 

case mapper .Res (/3 in ExHeap y) : 
target . Data(y) ; 

map<a , f}> (mapper , source, target); 

} 

case source. Eos() : 
target. Eos () ; 
source . CloseO ; 
target . CloseO ; 



Figure 1: An example of Sing* code. 



2. A Taste of Sing # 

In this section we take a closer look at Sing*, the programming language specifically de- 
signed for the development of programs that run in Singularity OS. We do so by means of a 
simple, yet rather comprehensive example that shows the main features of the language and 
of its type system. In the discussion that follows it is useful to keep in mind that Singularity 
channels consist of pairs of related endpoints, called the peers of the channel. Messages sent 
over one peer are received from the other peer, and vice versa. Each peer is associated 
with a FIFO buffer containing the messages sent to that peer that have not been received 
yet. Therefore, communication is asynchronous (send operations are non-blocking) and 
process synchronization must be explicitly implemented by means of suitable handshaking 
protocols. 

The code snippet in Figure [T] defines a polymorphic function map that transforms a 
stream of data of type a into a stream of data of type (3 through a provided mapperQ 
The function accepts two type arguments a and j3 and three proper arguments: a mapper 
endpoint that allows communication with a process that performs the actual processing 
of data; a source endpoint from which data to be processed is read; a target endpoint 
to which processed data is forwarded. For the time being, we postpone the discussion of 
the type annotations of these arguments and focus instead on the operational semantics of 
the function. We will come back to types shortly, when we discuss static analysis. The 
switch receive construct (lines 4-17) is used to receive messages from an endpoint, and 
to dispatch the control flow to various cases depending on the kind of message that is 
received. Each case block specifies the endpoint from which a message is expected and the 

^This function can be thought of as the communication-oriented counterpart of the higher-order, list- 
processing map function defined in the standard library of virtually all functional programming languages. 
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tag of the message. In this example, two kinds of messages can be received from the source 
endpoint: either a Data-tagged message (lines 5-11) or a Eos-tagged message (lines 13-16). 
A Data-tagged message contains a chunk of data to be processed, which is bound to the local 
variable x (line 5). The data is sent in an Arg-tagged message on the mapper endpoint for 
processing (line 6), the result is received from the same endpoint as a Res-tagged message, 
stored in the local variable y (line 8) and forwarded on the target endpoint as another 
outgoing Data-tagged message (line 9). Finally, the map function is invoked recursively so 
that further data can be processed (line 10). An Eos-tagged message flags the fact that the 
incoming stream of data is finished (line 13). When this happens, the same kind of message 
is sent on the target endpoint (line 14) and both the source and the target endpoints 
are closed (lines 15 and 16). 

We now illustrate the meaning of the type annotations and their relevance with respect 
to static analysis. The in ExHeap annotations state that all the names in this example 
denote pointers to objects allocated on the exchange heap. Some of these objects (like 
those pointed to by source and target) represent communication endpoints, others (those 
pointed to by x and y) represent data contained in messages. Static analysis of Sing* 
programs aims at providing strong guarantees on the absence of errors deriving from com- 
munications and the usage of heap-allocated objects. 

Regarding communications, the correctness of this code fragment relies on the assump- 
tion that the process(es) using the peer endpoints of mapper, source, and target are able 
to deal with the message types as they are received/sent from within map. For instance, 
map assumes to receive a Res-tagged message after it has sent an Arg-tagged message on 
mapper. It also assumes that only Data-tagged and Eos-tagged messages can be received 
from source and sent to target, and that after an Eos-tagged message is received no fur- 
ther message can be received from it. No classical type associated with mapper or source or 
target is able to capture these temporal dependencies between such different usages of the 
same object at different times. The designers of Sing* have consequently devised channel 
contracts describing the allowed communication patterns on a given endpoint. Consider, 
for example, the polymorphic contracts Mapper<a,/3> and Stream<a> below: 

contract Mapper<a,/3> { contract Stream<o> { 

message Arg(a in ExHeap) ; message Data(a in ExHeap) ; 

message Res(/3 in ExHeap); message Eos(); 

state WAIT ARG state START 



A contract is made of a finite set of message specifications and a finite set of states 
connected by transitions. Each message specification begins with the message keyword and 
is followed by the tag of the message and the type of its arguments. For instance, the 
Stream<a> contract defines the Data-tagged message with an argument of type a and the 
Eos-tagged message with no arguments. The state of the contract determines the state 
in which the endpoint associated with the contract is and this, in turn, determines which 
messages can be sent /received. The same contract can have multiple states, each with a pos- 
sibly different set of messages that can be sent/received, therefore capturing the behavioral 




{ Data! ->■ START; 

Eos! — > END; } 
state END { } 



} 



} 
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nature of endpoints. In Stream<a> we have a START state from which two kinds of message 
can be sent: if a Data-tagged message is sent, the contract remains in the START state; if 
a Eos-tagged message is sent, the contract transits to the END state from which no further 
transitions are possible. Communication errors are avoided by associating the two peers of 
a channel with types that are complementary, in that they specify complementary actions. 
This is achieved in Sing* with the exp<C:s> and imp<C:s> type constructors that, given a 
contract C and a state s of C, respectively denote the so-called exporting and importing views 
of C when in state s. For the sake of hindsight, it is useful to think of the exporting view as of 
the type of the provider of the behavior specified in the contract, and of the importing view 
as of the type of the consumer of the behavior specified in the contract. On the one hand, 
the map function in Figure [T] accepts a mapper argument of type imp<Map<a,/3> :WAIT_ARG> 
since it consumes the mapping service accessible through the mapper endpoint and a source 
argument of type imp<Stream<a> : START> since it consumes the source stream of data 
to be processed. On the other hand, the function accepts a target argument of type 
exp<Stream</3> : START> since it produces a new stream of data on the target endpoint. In 
the code fragment in Figure [TJ the endpoint target has type exp<Stream</3> : START> on 
line 9, the output of a Data-tagged message is allowed by the exporting view of Stream</3> 
in this state, and the new type of target on line 10 is again exp<Stream</3> : START>. Its 
type turns to exp<Stream<a> :END> from line 14 to line 15, when the Eos-tagged message 
is received. The endpoint mapper has type imp<Mapper<a,/3> :WAIT_ARG> on line 6. The 
importing view of Mapper<a , (3> allows sending a Arg-tagged message in this state, hence 
the type of mapper turns to imp<Mapper<a , f3> : SEND_RES> in lines 7 and back to type 
imp<Mapper<a , f3> : WAIT_ARG> from line 8 to line 9. 

A major complication of the copyless paradigm derives from the fact that communicated 
objects are not copied from the sender to the receiver, but rather pointers to allocated 
objects are passed around. This can easily invalidate the ownership invariant if special 
attention is not payed to whom is entitled to access which objects. Given these premises, 
it is natural to think of a type discipline controlling the ownership of allocated objects, 
whereby at any given time every allocated object is owned by one (and only one) process. 
Whenever (the pointer to) an allocated object is sent as a message, its ownership is also 
transferred from the sender to the receiver. In the example of Figure [H the function map 
becomes the owner of data x in line 5. When x is sent on endpoint mapper, the ownership 
of x is transferred from map to whichever process is receiving messages on mapper's peer 
endpoint. Similarly, map acquires the ownership of y on line 8, and ceases it in the subsequent 
line. Overall it seems like map is well balanced, in the sense that everything it acquires it 
also released. In fact, as mapper, source, and target are also allocated on the exchange 
heap, we should care also for map's arguments. Upon invocation of map, the ownership 
of these three arguments transfers from the caller to map, but when map terminates, only 
the ownership of mapper returns to the caller, since source and target are closed (and 
deallocated) within map on lines 15 and 16. This is the reason why the types of source 
and target in the header of map are annotated with a [Claims] clause indicating that map 
retains the ownership of these two arguments even after it has returned. 

From the previous discussion it would seem plausible to formalize Sing* using a process 
calculus equipped with a suitable session type system. Session types capture very well the 
sort of protocols described by Sing* contracts and one could hope that, by imposing a linear 
usage on entities, the problems regarding the ownership of heap-allocated objects would be 
easily solved. In practice, things are a little more involved than this because, somewhat 
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surprisingly, linearity alone is too weak to guarantee the absence of memory leaks, which 
occur when every reference to an heap-allocated object is lost. We devote the rest of this 
section to illustrating this issue through a couple of simple examples. Consider the function: 

void f oo ( [Claims] imp<C : START> in ExHeap e, 
[Claims] exp<C:START> in ExHeap f) 
{ e.Arg(f) ; e.CloseO ; } 

which accepts two endpoints e and f allocated in the exchange heap, sends endpoint f as an 
Arg-tagged message on e, and closes e. The [Claims] annotations in the function header 
are motivated by the fact that one of the two arguments is sent away in a message, while the 
other is properly deallocated within the function. Yet, this function may produce a leak if e 
and f are the peer endpoints of the same channel. If this is the case, only the e endpoint is 
properly deallocated while every reference to f is lost. Note that the f oo function behaves 
correctly with respect to the Sing* contract 

contract C { 
message Arg(exp<C : START> in ExHeap); 
state START { Arg? -> END; } 
state END { } 

} 

whose only apparent anomaly is the implicit recursion in the type of the argument of the 
Arg message, which refers to the contract C being defined. A simple variation of f oo and 
C, however, is equally dangerous and does not even need this form of implicit recursion: 

void bar( [Claims] imp<D:START> in ExHeap e, 
[Claims] exp<D:START> in ExHeap f) 
{ e.Arg<exp<D:START»(f ) ; e.CloseO; } 

In this case, the Arg-tagged message is polymorphic (it accepts a linear argument of 
any type) and the contract D is defined as: 

contract D { 
message Arg<a>(a in ExHeap); 
state START { Arg? ->■ END; } 
state END { } 

} 

These examples show that, although it makes sense to allow the types exp<C:START> 
and exp<D : START> in general, their specific occurrences in the definition of C and in the body 
of bar are problematic. We will see why this is the case in Section and we shall devise a 
purely type-theoretic framework that avoids these problems. Remarkably, the f oo function 
is ill typed also in Sing* [8], although the motivations for considering foo dangerous come 
from the implementation details of ownership transfer rather than from the memory leaks 
that foo can produce (see Section [7] for a more detailed discussion). 
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Table 1: Syntax of types. 



Type t 


::= qT 


(qualified endpoint type) 


Qualifier q 


::= lin 


(linear) 




un 


(unrestricted) 


Endpoint Type T 


::= end 


(termination) 




a 


(type variable) 




{hniioiKtj-Tihei 


(internal choice) 




{tmi{ai)(ti).Ti}iei 


(external choice) 




rec a.T 


(recursive type) 



3. Types 

We introduce some notation for the type language: we assume an infinite set of type variables 
ranged over by a, /3, . . . ; we use t, s, . . . to range over types, q to range over qualifiers, 
and T, 5, . . . to range over endpoint types. The syntax of types and endpoint types is 
defined in Table [TJ An endpoint type describes the allowed behavior of a process with 
respect to a particular endpoint. The process may send messages over the endpoint, receive 
messages from the endpoint, and deallocate the endpoint. The endpoint type end denotes an 
endpoint on which no input /output operation is possible and that can only be deallocated. 
An internal choice {!mj(aj)(ij).Tj}j g / denotes an endpoint on which a process may send any 
message with tag mj for i E I. The message has a type parameter cti, which the process 
can instantiate with any endpoint type (but we will impose some restrictions in Section [5]), 
and an argument of type ij. Depending on the tag mj of the message, the endpoint can be 
used thereafter according to the endpoint type Tj. In a dual manner, an external choice 
{?mj(aj)(ij).Tj}j G j denotes and endpoint from which a process must be ready to receive any 
message with tag mj for i £ I. Again, a, is the type parameter of the message and ij denotes 
the type of the message's argument. Depending on the tag mj of the received message, the 
endpoint is to be used according to Tj. The duality between internal and external choices 
regards not only the dual send/receive behaviors of processes obeying these types, but 
also the quantification of type parameters in messages, which we can think universally 
quantified in internal choices (the sender chooses how to instantiate the type variable) 
and existentially quantified in external choices (the receiver does not know the type with 
which the type variable has been instantiated). In endpoint types {!mj(aj)(£j).Tj}j e / and 
{?mj(aj)(tj).Tj}j G j we assume that mj = m^ implies i = j. That is, the tag mj of the message 
that is sent or received identifies a unique continuation Tj. Terms rec a.T can be used to 
specify recursive behaviors, as usual. The role of type variables a is twofold, depending on 
whether they are bound by a recursion rec a.T or by a prefix m(a)(t) in a choice: they 
either represent recursion points, like a in rec a.lm(f3)(t).a, or abstracted endpoint types, 
like a in !m(a)(lin ?m' (/?)(£). a). end. We will see plenty of examples of both usages in the 
following. 

Even though the type system focuses on linear objects allocated on the exchange heap, 
the type language must be expressive enough to describe Singularity OS entities like system- 
wide services or Sing* functions and procedures. For this reason, we distinguish linear 
resources from unrestricted ones and, along the lines of |22t 112]. we define types as qualified 
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Table 2: Well-formedness rules for endpoint types. 
(WF-Var) (WF-Rec) 

AoiAJhend 

AojAJr-a A ; A : lh rec a.T 

(WF-Prefix) 

t £{!,?} (AoUAMj^ (' gJ ) A ; A I; lh Tj ^ eJ - > 
A ;A : lh f 5i).Ti} ieJ 



endpoint types. A qualifier is either ' I i n ' , denoting a linear endpoint type or 'un', denoting 
an unrestricted endpoint type. Endpoints with a linear type must be owned by exactly one 
process at any given time, whereas endpoints with an unrestricted type can be owned by 
several (possibly zero) processes at the same time. Clearly, not every endpoint type can 
be qualified as unrestricted, for the type system relies fundamentally on linearity in order 
to enforce its properties. In the following we limit the use of the 'un' qualifier to endpoint 
types of the form rec a.{!mj(aj)(ij).a}j g /, whose main characteristic is that they do not 
change over time (each continuation after an output action is a, that is the whole endpoint 
type itself). In a sense, they are not behavioral types, which intuitively explains why they 
can be safely qualified as unrestricted. 

Here are some conventions regarding types and endpoint types: 

• we sometimes use an infix notation for internal and external choices and write 

!mi(ai)(ti).Ti • • • \m n (a n )(t n ).T n instead of V-m{ai)(ti).Ti} ie{1 ^^ n} 

and 

?mi(ai)(<i).Ti H \- ?m n (a n )(t n ).T n instead of {?m i (o i )(t i ).Ti} i6 { 1) ... )n } 

• we omit the type variable specification (a) when useless (if the type variable occurs 
nowhere else) and write, for example, !m(i).T; 

• for the sake of simplicity, we formally study (endpoint) types where messages carry exactly 
one type/value argument, but we will be more liberal in the examples; 

• we write lin(i) and un(t) to mean that t is respectively linear and unrestricted. 

We have standard notions of free and bound type variables for (endpoint) types. The 
binders are rec and m(a)(t). In particular, rec a.T binds a in T and \m{a)(t).T where 
t £ {!, ?} binds a in ( and in T. We will write ftv(T) and btv(T) for the set of free 
and bound type variables of T. We require that type variables bound by a recursion rec 
must be guarded by a prefix (therefore a non-contractive endpoint type such as rec a. a 
is forbidden) and that type variables bound in (a) as in !m(a)(t).T can only occur in t 
and within the prefixes of T. We formalize this last requirement as a well-formedness 
predicate for types denoted by a judgment A ;A : lh T and inductively defined by the 
axioms and rules in Table The set A contains so-called outer variables (those that can 
occur everywhere) while the set A : contains so-called inner variables (those that can occur 
only within prefixes). Here and in the following we adopt the convention that A, A' denotes 
A U A' when A n A' = and is undefined otherwise; we also write A, a instead of A, {a}. 
We say that T is well formed with respect to A, written A lh T, if A; lh i is derivable. 
Well formedness restricts the expressiveness of types, in particular endpoint types such as 
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\m(a)(t).a and ?m{a)(t).a are not admitted because ill formed. We claim that ill- formed 
endpoint types have little practical utility: a process using an endpoint with type \m{a)(t).a 
knows the type with which a is instantiated while no process is capable of using an endpoint 
with type ?m(a)(t).a since nothing can be assumed about the endpoint type with which a 
is instantiated. 

In what follows we consider endpoint types modulo renaming of bound variables and 
the law rec a.T = T{rec a.T/a} where T{rec a.T/a} is the capture-avoiding substitution 
of rec a.T in place of every free occurrence of a in T. Whenever we want to reason on the 
structure of endpoint types, we will use a syntactic equality operator =. Therefore we have 
rec a.T ^ T{rec a.T/a} (recall that T cannot be a for contractivity) . 

Example 3.1. Consider the contracts Mapper<a,/3> and Stream<a> presented in Section^ 
We use the endpoint types 



to denote the Sing* types exp<Mapper<a , f}> : WAIT_ARG> and exp<Stream<a> : START> re- 
spectively. Recursion models loops in the contracts and each state of a contract corresponds 
to a particular subterm of T Mapper (a, 0) and Ts tr eam(«)- For instance, the Sing* type 
exp<Mapper<a , f3> : SEND_RES> is denoted by the endpoint type !Res(lin /3).T Mapper (a, j3). 
The type of message arguments are embedded within the endpoint types, like in session 
types but unlike Sing* where they are specified in separate message directives. The lin 
qualifiers correspond to the in ExHeap annotations and indicate that these message argu- 
ments are linear values. 

Observe that both endpoint types are open, as the type variables a and (3 occur free in 
them. We will see how to embed these endpoint types into a properly closed type for map 
in Example 13.31 ■ 

Duality is a binary relation between endpoint types that describe complementary ac- 
tions. Peer endpoints will be given dual endpoint types, so that processes accessing peer 
endpoints will interact without errors: if one of the two processes sends a message of some 
kind, the other process is able to receive a message of that kind; if one process has finished 
using an endpoint, the other process has finished too. 

Definition 3.1 (duality). We say that 3l is a duality relation if (T,S) G & implies either 

• T = S = end, or 

• T = {?mi(ai)(ti).Ti} ie i and S = {\mi(<Xi)(U)-Si}iei and (Tj, Si) G S 1 for every i G I, or 

• T = {\m{ati)(ti).Ti}i e i and S = {?mj(aj)(tj).5'j} ie / and (Tj, Si) G 9 for every i G /. 
We write oo for the largest duality relation and we say that T and S are dual if T M S. 

We will see that every well-formed endpoint type T has a dual - that we denote by 
T - which is intuitively obtained from T by swapping ?'s with !'s. The formal defini- 
tion of T, however, is complicated by the possible occurrence of recursion variables within 
prefixes. As an example, the dual of the endpoint type T = rec a.!m(/3)(a).end is not 
S = rec a.?m(/3)(a).end but rather rec a.?m(/?)(T).end. This is because, by unfolding the 
recursion in T, we obtain T = !m(/3)(T).end whose dual, ?m(/3)(T).end, is clearly different 
from S = ?m(/3) (<!?). end (duality does not change the type of message arguments). 

To provide a syntactic definition of dual endpoint type, we use an inner substitution 
operator {{■/■}} such that T{{S/a}} denotes T where every free occurrence of a within the 



^Mapper(oi) P) 
^Stream ( a ) 



rec 7.?Arg(lin a).!Res(lin /3).j 
rec 7.(!Data(lin a). 7 ® lEosQ.end) 
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prefixes of T has been replaced by S. Free occurrences of a that do not occur within a 
prefix of T are not substituted. For example, we have (\m(f3)(a).a){{S/a}} = \m((3)(S).a. 
Then, the dual of an endpoint type T is defined inductively on the structure of T, thus: 

end = end 

a = a 

rec a.T = rec a.T{{rec a.T/a}} 

{\mi{ai)(ti).Ti} ieI = {?mi{ai)(ti).T\} ieI 

{?m i (a i )(t i ).T i } ieI = {lm i {a i )(ti).T i } ieI 

Here are some important facts about well-formed endpoint types and duality: 
Proposition 3.1. The following properties hold: 

(1) T = T. 

(2) Ih T implies that T X T and Ih T. 

(3) A; {a} Ih T and A Ih S impl y A Ih T{ S/a}. 

(4) 0; {a} Ih T and Ih 5 imp/y T{S/a} = T{S/a}. 

Item (1) states that ~ is an involution. Item (2) states that T is well formed and 
dual of T when T is well formed. Item (3) states the expected property of well-formedness 
preservation under substitution of well- formed endpoint types. Finally, item (4) shows that 
duality does not affect the inner variables of an endpoint type and that, in fact, duality and 
substitution commute. 

Example 3.2. In Example 13.11 we have defined the endpoint types T Mapper (a, /3) and 
^stream ( a ) denoting the exp<Mapper<a , j3> : WAIT_ARG> and exp<Stream<a> : START> types 
in Sing*. The dual endpoint types of T Map per(a, /3) and Ts tr eam(aO are 

^M apper («, ft) = rec 7.!Arg(lin a).?Res(lin ft)_7 
7stream(a) = rec 7.(?Data(lin a) .7 + ?Eos().end) 

and they denote the imp<Mapper<a , ft> : WAIT_ARG> and imp<Stream<a> : START> types in 
Sing*. ■ 

Example 3.3 (function types). While Sing* is a procedural language, our formalization 
is based on a process algebra. Therefore, some Sing* entities like functions and function 
types that are not directly representable must be encoded. A function can be encoded as a 
process that waits for the arguments and sends the result of the computation. Callers of the 
function will therefore send the arguments and receive the result. Following this intuition, 
the type 

^map ft) — !Arg(lin T Mapper (a, ft)).!Arg(lin r Stream (a)).!Arg(lin T Stream (ft)).?Res().end 

seems like a good candidate for denoting the type of map in Figure HJ This type allows a 
caller of the function to supply (send) three arguments having type T Mapper (o;, ft), T Stream (a), 
and Tstream(ft) in this order. The lin qualifiers indicates that all the arguments are linear. 
Since map returns nothing, the Res-tagged message does not carry any useful value, but it 
models the synchronous semantics of function invocation. 

This encoding of the type of map does not distinguish arguments that are claimed by 
map from others that are not. The use of the lin qualifier in the encoding is mandated 
by the fact that the arguments are allocated in the exchange heap, but in this way the 
caller process permanently loses the ownership of the mapper argument, and this is not the 
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intended semantics of map. We can model the temporary ownership transfer as a pair of 
linear communications, by letting the (encoded) map function return any argument that is 
not claimed. Therefore, we patch the above endpoint type as follows: 

^map P) = !Arg(lin T Mapper (a, /3)).[- • -].?Arg(lin T Mapper (a, /3)).?Res().end 

The endpoint type T map (a, j3) describes the protocol for one particular invocation of the 
map function. A proper encoding of the type of map, which allows for multiple invocations 
and avoids interferences between independent invocations, is the following: 

imap = un rec 7.!lnvoke(a, /3}(lin T map (a, f3)).j 

Prior to invocation, a caller is supposed to create a fresh channel which is used for communi- 
cating with the process modeling the function. One endpoint, of type T map (a, f3), is retained 
by the caller, the other one, of type T map (a,/3), is sent upon invocation to the process mod- 
eling map. The recursion in t map permits multiple invocation of map, and the un qualifier 
indicates that map is unrestricted and can be invoked simultaneously and independently by 
multiple processes in the system. ■ 

The most common way to increase flexibility of a type system is to introduce a subtyping 
relation ^ that establishes an (asymmetric) compatibility between different types: any value 
of type t can be safely used where a value of type s is expected when t ^ s. In the flourishing 
literature on session types several notions of subtyping have been put forward [TOl El [221 
[20] . We define subtyping in pretty much the same way as in [10j [9] . 

Definition 3.2 (subtyping). Let < be the least preorder on qualifiers such that un < lin. 
We say that y is a coinductive subtyping if: 

• (q T, q' S) G 5? implies q < q' and (T, S) G y, and 

• (T, S) G y implies either: 

(1) T = S = end, or 

(2) T = S = a, or 

(3) T = {?mi(ati)(ti).Ti} ieI and 5 = {?mi(aj)(sj).Sj}i e j with I C J and (i;,s;) G y and 
(Ti,Si) G y for every i G /, or 

(4) T = {\mi(ai)(ti).Ti} ieI and S = {!mj(a i )(s i ).5'j}i e j with J C I and (sj,^) G and 
(Tj, Si) G y for every i G J. 

We write ^ for the largest coinductive subtyping. 

Items (1) and (2) account for reflexivity of subtyping when T and S are both end or 
the same type variable; items (3) and (4) are the usual covariant and contravariant rules for 
inputs and outputs respectively. Observe that subtyping is always covariant with respect 
to the continuations. Two types qi T and q2 S are related by subtyping if so are T and S 
and if q± is no more stringent than q<i- In particular, it is safe to use an unrestricted value 
where a linear one is expected. 

The reader may verify that subtyping is a pre-order: 

Proposition 3.2. is reflexive and transitive. 

Proof sketch. The proofs of both properties are easy exercises 
suffices to show that 

y = {(h,t 2 ) \3s:t 1 ^sks^t 2 }U{(T 1 ,T 2 ) \3S 
is a coinductive subtyping. 



In the case of transitivity it 
Ti < 5 & S ^ T 2 } 

□ 
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The following property shows that duality is contravariant with respect to subtyping. 
It is a standard property of session type theories, except that in our case it holds only when 
the two endpoint types being related have no free type variables occurring at the top level 
(outside any prefix), for otherwise their duals are undefined (Proposition 13. 1 1 ) . 

Proposition 3.3. Let Ih T and Ih S. Then T ^ S if and only ifS^T. 

Example 3.4. In Example 13.31 we have suggested a representation for the function type 
s — > t as the type [s — > tj defined thus: 

[s — > £] = un rec <x!lnvoke(lin ?Arg(s).!Res(i).end).a 

It is easy to verify that [si — > ^ [sj — > t 2 } if and only if s 2 ^ «i and £1^*2- That 
is, the subtyping relation between encoded function types is consistent with the standard 
subtyping between function types, which is contravariant in the domain and covariant in 
the co-domain. 

Another way to interpret an endpoint having type 

rec a. ! Invoke (i). a 

is as an object with one method Invoke. Sending a Invoke-tagged message on the endpoint 
means invoking the method (incidentally, this is the terminology adopted in SmallTalk) , and 
after the invocation the object is available again with the same interface. We can generalize 
the type above to 

rec a.{\mi(ti).a}i e i 

for representing objects with multiple methods mj. According to the definition of subtyping 
we have 

rec a.{\mi(ti).a} ie i < rec a.{\mj(tj).a} jeJ 
whenever J C J, which corresponds the same notion of subtyping used in object-oriented 
language (it is safe to use an object offering more methods where one offering fewer methods 
is expected). ■ 



4. Syntax and Semantics of Processes 

We assume the existence of an infinite set Pointers of linear pointers (or simply pointers) 
ranged over by a, b, . . . , of an infinite set Variables of variables ranged over by x, y, . . . , and 
of an infinite set of process variables ranged over by X, Y, ... . We define the set Pointers of 
unrestricted pointers as Pointers = {a \ a € Pointers}. We assume Pointers, Pointers, 
and Variables be pairwise disjoint, we let u, v , ... range over names, which are elements 
of Pointers U Pointers U Variables, and we let v, w, ... range over values, which are 
elements of Pointers U Pointers. 

Processes, ranged over by P, Q, . . . , are defined by the grammar in Table O The 
calculus of processes is basically a monadic pi calculus equipped with tag-based message 
dispatching and primitives for handling heap-allocated endpoints. The crucial aspect of the 
calculus is that names are pointers to the heap and channels are concretely represented as 
structures allocated on the heap. Pointers can be either linear or unrestricted: a linear 
pointer must be owned by exactly one process at any given point in time; an unrestricted 
pointer can be owned by several (possibly zero) processes at any time. In practice the two 
kinds of pointers are indistinguishable and range over the same address space, but in the 
calculus we decorate unrestricted pointers with a bar to reason formally on the different 
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Table 3: Syntax of processes. 



Process P ::= 


(idle) 


close(u) 


(close endpoint) 


open(a : T,a : T).P 


(open linear channel) 


open(a : T).P 


(open unrestricted channel) 


u\m(T)(u).P 


(send) 


J2 ie iutm(ai)(xi : ti).Pi 


(receive) 


P©P 


(conditional process) 


P j P 


(parallel composition) 


X 


(process variable) 


rec X.P 


(recursive process) 



ownership invariants. The term denotes the idle process that performs no action. The 
term open(o : T,b : S).P denotes a process that creates a linear channel, represented as a 
pair of endpoints a of type T and b of type S, and continues as P. We will say that b is the 
peer endpoint of a and vice- versa. The term open(o : T).P denotes a process that creates 
an unrestricted channel, represented as an endpoint a of type T along with an unrestricted 
pointer a of type T, and continues as P. The term close(u) denotes a process closing 
and deallocating the endpoint u. The term u\m(T)(v).P denotes a process that sends a 
message m(T)(v) on the endpoint u and continues as P. The message is made of a tag m 
along with its parameter v. The endpoint type T instantiates the type variable in the type 
of u. For consistency with the type language we only consider monadic communications 
where every message has exactly one type/value parameter. The generalization to polyadic 
communications, which we will occasionally use in the examples, does not pose substantial 
problems. The term J2iei u ^ m i( a i)( x i '■ U)-Pi denotes a process that waits for a message 
from the endpoint u. The tag m; of the received message determines the continuation Pj 
where the variable Xi is instantiated with the parameter of the message. Sometimes we will 

write u?mi(ai)(j;i : ii).Pi H \-u?m n (a n )(x n : t n ).P n in place of Y2=l u?m(ai)(xi : ^).p0 

The term P ®Q denotes a process that internally decides whether to behave as P or as Q. 
We do not specify the actual condition that determines the decision, as this is irrelevant for 
our purposes. To improve readability, in some of the examples we will use a more concrete 
syntax. As usual, terms rec X.P and X serve to denote recursive processes, while P | Q 
denotes the parallel composition of P and Q. 

Table S] collects the definitions of free names fn(-) and bound names bn(-) for processes. 
Beware that a process open(a : T).P implicitly binds a in addition to a in P. In the same 
table we also define the sets of free type variables ftv(-) and of bound type variables of a 
process. Note that the set of bound type variables only includes those variables occurring in 
input prefixes of the process, not the type variables bound within endpoint types occurring 
in the process. The construct rec X.P is the only binder for process variables. The sets 
of free process variables fpv(-) and of bound process variables bpv(-) are standard. We 
identify processes up to renaming of bound names/type variables/process variables and 

2 We require the endpoint u to be the same in all branches of the receive construct, while switch receive 
in Sing* allows waiting for messages coming from different endpoints. This generalization would not affect 
our formalization in any substantial way, save for slightly more complicated typing rules. 
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Table 4: Free and bound names/type variables in processes. 



fn(U J = fn(A ) 




rt 

V 


in(close(uj j 




i u i 


in(open(a : 1 , : o ).r) 




fn(^j \ {a,b\ 


±n(open(a : i J.-r J 




1ti(P) \ {a, a j 


fn(«!m(T}(u).P) 


= 


{tt,t;} U fn(P) 


fn (Eie/ u?m i(ai}( 2; i : U)-Pi) 


= 


MuU ie /(fn(P)\{^}) 


fn(P © Q) = fn(P | Q) 




fn(P) U fn(Q) 


±n(rec A..r) 






bn(UJ = bn(close(uj) = dh[A ) 




V 


bn(open(a .1,0. o).P) 




{a, b\ U bn(.r) 


bn(open(o : T).P) 


— 


{a, a} Ubn(P) 


bn(u\m{T)(v).P) = bn(rec X.P) 


= 


bn(P) 


bn (LiG/ U - m A Q; i)( X i : til-Pi) 


— 


Ue/({^}Ubn(P)) 


bn(^ Qd Q) — bn(^ C^/J 




Xxn\r) U bn^ J 


Itv^U J = ttv^close^uJJ = itv^A J 




rt 


ftv(open(a : T,b : S).P) 




ftv(T) U ftv(S) U ftv(P) 


ftv(open(a : T).P) = ftv(u\m(T)(v).P) 




f tv(T) U f tv(P) 


ftv (Ei G / u?mi(ai)(xi : U).Pi) 




U ie7 ((ftv&)Uftv(P))\{c*0) 


f tv(P © Q) = f tv(P | Q) 




f tv(P) U f tv(Q) 


ftv(rec X.P) 




ftv(P) 


btv(O) = btv(close(u)) = btv(X) 







btv(open(a : T, b : S).P) = btv(open(a : T).P) 




btv(P) 


btv(u\m(T)(v).P) = btv(rec X.P) 




btv(P) 


btv (Eie/ n?m i(«i)( 2; i : U)-Pi) 




U 6/ ({a i }Ubtv(P i )) 


btv(P©Q) =btv(P|Q) 




btv(P) U btv(Q) 



let P{v/x}, P{T/a}, and P{Q/X} denote the standard capture-avoiding substitutions of 
variables /type variables/process variables with values /endpoint types/processes. 

Example 4.1. Let us encode the map function in Figure [U using the syntax of our process 
calculus. As anticipated in Example 13.31 the idea is to represent map as a process that 
permanently accepts invocations and handles them. For this reason we need an endpoint, 
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Table 5: Syntax of heaps and queues. 






Heap fi ::= (empty) Queue Q :: = 




(empty) 


a i y [a, Q] (endpoint) 


m(T)(v) 


(message) 


fi, fi (composition) 


£1 ::£} 


(composition) 



say c, to which invocation requests are sent and we define the MAP(c) process thus: 

MAP(c) = rec X. c? Invoke {a, 0){z : lin T ma p (q, ~fj)).{X | BODY(q, j3, z)) 
B0DY(a,/3,z) = zlkrg{mapper : li n T Mapper (a , /3)). 

zl krg{source : lin r Str eam(a))- 

zlkrg{target : lin T Stream (/?)). 

rec Y.( soMrce?Data(x : lin a). mapper lArg(x). 

mapper?Res(y : lin /3).tan/ei!Data(y).Y 
+ source?Eos().target\EosQ. 

z !Arg( mapper ).z!Res(). 

(closed) | close(so?/rce) | close(tar<7ei))) 

The process MAP(c) repeatedly reads Invoke-tagged messages from c. Each message carries 
another endpoint z that represents a private session established between the caller and the 
callee, whose purpose is to make sure that no interference occurs between independent 
invocations of the service. Note that z has type T^ &v {a, f3), the dual of T map (a, (3), since it is 
the endpoint handed over by the caller from which the callee will receive the arguments and 
send the result. The body of the map function is encoded by the BODY(a, f3, z) process, 
which begins by reading the three arguments mapper, source, and target. Then, the process 
enters its main loop where messages are received from source, processed through mapper, 
and finally sent on target. Overall the structure of the process closely follows that of the code 
in Figure [U where the branch operator is used for modeling the switch receive construct. 
The only remarkable difference occurs after the input of a Eos-tagged message, where the 
mapper argument is returned to the caller so as to model the temporary ownership transfer 
that was implicitly indicated by the lack of the [Claims] annotation in map. At this point 
the z endpoint serves no other purpose and is closed along with source and target. ■ 

To state the operational semantics of processes we need a formal definition of the 
exchange heap (or simply heap), which is given in Table [SJ Heaps, ranged over by [i, are 
term representations of finite maps from pointers to heap objects: the term denotes the 
empty heap, in which no object is allocated; the term a i-> [b, £}] denotes a heap made of an 
endpoint located at a. The endpoint is a structure containing another pointer b and a queue 
£} of messages waiting to be read from a. Heap compositions fi, // are defined only when the 
domains of the heaps being composed, which we denote by dom(/x) and dom(^'), are disjoint. 
We assume that heaps are equal up to commutativity and associativity of composition and 
that is neutral for composition. Queues, ranged over by 0, are finite ordered sequences 
of messages mi(Ti)(vi) :: • • • :: m n (T n )(y n ), where a message m(T)(v) is identified by its tag 
m, the endpoint type T with which its type argument has been instantiated, and its value 
argument v. We build queues from the empty queue e and concatenation of messages by 
means of ::. We assume that queues are equal up to associativity of :: and that e is neutral 
for ::. The T component in the enqueued messages must be understood as a technical 
annotation that helps reasoning on the formal properties of the model. In particular, it 
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Table 6: Structural congruence. 



(S-Idle) (S-Comm) (S-Assoc) 

P\0 = P P\Q = Q\P P\{Q\R) = (P\Q)\R 



Table 7: Operational semantics of processes. 



(R-Open Linear Channel) 

(fi; open(a : T, b : S).P) ->(/i,oH [b, e], b i-4 [a, e];P) 

(R-Open Unrestricted Channel) (R-Choice Left) (R-Choice Right) 

(//;open(a : T).P) ->• (/i,ah> [a,e];P) (//; P © Q) -4 0; P) (/i; P 8 Q) ->(//; Q) 

(R-Send Linear) 

(/i,oi-> [6,0], 64 [o,0 / ];o!m(T)(v).P) -4 (/^aH- [6,0], 6 4 [a,0' :: m(T)(v)]; P) 
(R-Send Unrestricted) 

(ji,ai-t [a,0];a!m(T)(v).P) (/i,a 4 [a,0 :: m(T)(v)];P) 

(R-Receive) 

(/x,ai-4 [6,m fc (T)(v) :: 0]; £ igJ aTm^)^ : U).P$ -4 (/i,a i-4 [6, 0]; P fc {T/a fc }{v/x fc }) 

(R-Rec) 

(^;rec I.P) 4 (//; P{rec X.P/X}) 
(R-Par) (R-Struct) 

0^4-O^pQ p^P (j^p^jM) q'^q 

(n;P\Q)^(ji';P'\Q) (fi; P) -4 (//; Q) 



does not imply that a practical implementation of the calculus must necessarily provide a 
runtime representation of endpoint typesH 

We define the operational semantics of processes as the combination of a structural 
congruence relation, which equates processes we do not want to distinguish, and a reduction 
relation. Structural congruence, denoted by =, is the least congruence relation defined by 
the axioms in Tableland closed under parallel composition. Essentially, the axioms state 
that | is commutative, associative, and has as neutral element. 

Processes communicate by means of endpoints that are allocated on the heap. Conse- 
quently, the reduction relation defines the transitions of systems rather than of processes, 
where a system is a pair (//; P) of a heap ji and a process P. The reduction relation 
— » is inductively defined in Table we comment on the rules in the following paragraphs. 
Rule (R-Open Linear Channel) creates a new linear channel, which consists of two fresh 
endpoints with empty queues and mutually referring to each other. The mutual references 
are needed since the messages sent using one of the endpoints will be enqueued into the 



Sing* does require a runtime representation of endpoint types because its expression language is equipped 
with a dynamic cast operator. 
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other peer. Rule (R-Open Unrestricted Channel) creates a new unrestricted channel, 
which consists of a single endpoint with empty queue. The reference in the endpoint is 
initialized with a pointer to itself. This way, by inspecting the b component of an end- 
point a i — ^ [b, 0] it is possible to understand whether the endpoint belongs to a linear 
or to an unrestricted channel, as we respectively have either a 7^ b or a = b. This dis- 
tinction is necessary in the reductions defining the semantics of outputs, as we will see 
shortly. In both (R-Open Linear Channel) and (R-Open Unrestricted Channel) 
we implicitly rename bound names to make sure that the newly introduced pointers do not 
already occur in dom(u), for otherwise the heap in the resulting system would be undefined. 
Rules (R-Choice Left) and (R-Choice Right) describe the standard reduction of con- 
ditional processes. Rules (R-Send Linear) and (R-Send Unrestricted) describe the 
output of a message m(T)(v) on the endpoint a of a linear channel and on the endpoint a 
of an unrestricted channel, respectively. In the former case, the message is enqueued at the 
end of a's peer endpoint queue. In the latter case, the message is enqueued in the only 
available queue. Rule (R- Receive) describes the input of a message from the endpoint a. 
The message at the front of a's queue is removed from the queue, its tag is used for selecting 
some branch k € /, and its type and value arguments instantiate the type variable and 
variable x& . If the queue is not empty and the first message in the queue does not match any 
of the tags {mj | i G /}, then no reduction occurs and the process is stuck. Rule (R-Rec) 
describes the usual unfolding of a recursive process. Rule (R-Par) closes reductions under 
parallel composition. Observe that the heap is treated globally, even when it is only a 
sub-process to reduce. Finally, rule (R-Struct) describes reductions modulo structural 
congruence. There is no reduction for close(a) processes. In principle, close(o) should 
deallocate the endpoint located at a and remove the association for a from the heap. In the 
formal model it is technically convenient to treat close(a) processes as persistent because, 
in this way, we keep track of the pointers that have been properly deallocated. We will see 
that this information is crucial in the definition of well-behaved processes (Definition 14.21) . 
A process willing to deallocate a pointer a and to continue as P afterwards can be modeled 
as close(a) | P. In the following we write for the reflexive, transitive closure of — > and 
we write (fi; P) if there exist no \j! and P' such that (/i; P) — > (//; P'). 

In this work we characterize well-behaved systems as those that are free from faults, 
leaks, and communication errors: a fault is an attempt to use a pointer not corresponding 
to an allocated object or to use a pointer in some way which is not allowed by the object 
it refers to; a leak is a region of the heap that some process allocates and that becomes 
unreachable because no reference to it is directly or indirectly available to the processes in 
the system; a communication error occurs if some process receives a message of unexpected 
type. We conclude this section formalizing these properties. To do so, we need to define 
the reachability of a heap object with respect to a set of root pointers. Intuitively, a process 
P may directly reach any object located at some pointer in the set f n(i-*) (we can think of 
the pointers in f n(P) as of the local variables of the process stored on its stack); from these 
pointers, the process may reach other heap objects by reading messages from the endpoints 
it can reach, and so forth. 

Definition 4.1 (reachable pointers). We say that c is reachable from a in fx, notation 
c -<n a, if a h-> [b,Q :: m(T)(c) :: Q'] € /U. We write =4^ for the reflexive, transitive closure of 
. Let reach(yl, /j,) = {c € Pointers | 3a £ A : c a}. 
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Observe that reach(^4, fj,) C Pointers for every A C Pointers U Pointers and 
Also, according to this definition nothing is reachable from an unrestricted pointer. The 
rationale is that we will use reach(-, •) only to define the ownership invariant, for which the 
only pointers that matter are the linear ones. We now define well-behaved systems formally. 

Definition 4.2 (well-behaved process). We say that P is well behaved if (0;P) => (fJ,; Q) 
implies: 

(1) dom(/i) = reach(f n(Q), /x); 

(2) Q = Pi\P 2 implies reach(fn(Pi),//) n reach(f n(P 2 ), A*) = 0; 

(3) Q = Pi | Pj and (/x;Pl) where Pi does not have unguarded parallel compositions 
imply either P\ = or Pi = close(a) or Pi = J2i<=i o? m i(a«)(£j : ii)-Pj and, in the last 
two cases, a h-> [6, e] £ /i. 

In words, a process P is well behaved if every residual of P reachable from a config- 
uration where the heap is empty satisfies a number of conditions. Conditions (1) and (2) 
require the absence of faults and leaks. Indeed, condition (1) states that every allocated 
pointer in the heap is reachable by one process, and that every reachable pointer corre- 
sponds to an object allocated in the heap. Condition (2) states that processes are isolated, 
namely that no linear pointer is reachable from two or more distinct processes. Because of 
the definition of reachable pointers, though, it may be possible that two or more processes 
share the same unrestricted pointer. Since processes of the form close(a) are persistent, 
this condition also requires the absence of faults deriving from multiple deallocations of the 
same endpoint or from the use of deallocated endpoints. Condition (3) requires the absence 
of communication errors, namely that if (//; Q) is stuck (no reduction is possible), then 
it is because every non-terminated process in Q is waiting for a message on an endpoint 
having an empty queue. This configuration corresponds to a genuine deadlock where every 
process in some set is waiting for a message that is to be sent by another process in the 
same set. Condition (3) also ensures the absence of so-called orphan messages: no message 
accumulates in the queue of closed endpoints. We only consider initial configurations with 
an empty heap for two reasons: first, we take the point of view that initially there are no 
allocated objects; second, since we will need a well-typed predicate for heaps and we do not 
want to verify heap well-typedness at runtime, we will make sure that the empty heap is 
trivially well typed. 

We conclude this section with a few examples of ill-behaved processes to illustrate the 
sort of errors we aim to avoid with our static type system: 

• The process open(a :T,b : S).0 violates condition (1), since it allocates two endpoints a 
and b and forgets them, thus generating a leak. 

• The process open(a : T,b : 5).(close(a) | close(a) | close(fr)) violates condition (2), since 
it deallocates the same endpoint a twice. This is an example of fault. 

• The process open(o : T,b : S').(a!m().close(a) | 6?m'().close(6)) violates condition (3), 
since it reduces to a parallel composition of subprocesses where one has sent an m-tagged 
message, but the other one was expecting an m'-tagged message. 

• The process open(a : T,b : 5 , ).a!m().6?m().(close(a) | close(fe)) violates condition (3), 
since it reduces to a stuck process that attempts at sending an m-tagged message using 
the unrestricted pointer a, while in fact a is a linear pointer. 
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5. Type System 

5.1. Weighing Types. We aim at denning a type system such that well- typed processes 
are well behaved. In session type systems, from which we draw inspiration, each action 
performed by a process using a certain endpoint must be matched by a corresponding action 
in the type associated with the endpoint, and the continuation process after that action must 
behave according the continuation in the endpoint type. Following this intuition, the reader 
may verify that the process BODY (Example 14. ip uses the endpoint z correctly with respect 
to the endpoint type T map (a, 0) (Example 13. 3p . Analogous observations can be made for the 
other endpoints {mapper, source, target) received from z and subsequently used in BODY. 
Linearity makes sure that a process owning an endpoint must use the endpoint (according 
to its type), or it must delegate it to another process. Endpoints cannot be simply forgotten 
and this is essential in guaranteeing the absence of leaks. In Example 14. II there is a number 
of endpoints involved: c is owned permanently by MAP; z is owned by BODY until an Eos- 
tagged message is received, at which point it is deallocated; source and target are acquired 
by BODY and deallocated when no longer in use; finally, mapper is acquired by BODY from 
the caller and returned to the caller when BODY ends. Overall, MAP is evenly balanced 
as far as the ownership of linear endpoints is concerned. 

Nonetheless, as we have anticipated in Section [2j there are apparently well-typed pro- 
cesses that lead to a violation of the ownership invariant. A first example is the process 

P = open(a : T\,b : T2).a!m(6).close(a) (5-1) 

where 

T\ = !m(lin T^.end and T2 = rec a.?m(lin a). end . 

The process P begins by creating two endpoints a and b with dual endpoint types. The 
fact that T\ = T2 ensures the absence of communication errors, as each action performed 
on one endpoint is matched by a corresponding co-action performed on the corresponding 
peer. After its creation, endpoint b is sent over endpoint a. Observe that, according to T\, 
the process is entitled to send an m-tagged message with argument of type T2 on a and b 
has precisely that type. After the output operation, the process no longer owns endpoint b 
and endpoint a is deallocated. Apparently, P behaves correctly while in fact it generates a 
leak, as we can see from its reduction: 

(0;P) 4(a4 [b,e],b h-» [a, e]; a!m(6).close(a)) ->(o4 [b,e],b i-» [a,m(6)]; close(a)) 

In the final, stable configuration we have reach(f n(close(a)), /i) = reach({a}, fx) = 
{a} (recall that b is not reachable from a even though its peer is) while dom(/i) = {a, b}. In 
particular, the endpoint b is no longer reachable and this configuration violates condition (1) 
of Definition 14.21 Additionally, if there were some mechanism for accessing b (for example, 
by peeking into the endpoint located at a) and for reading the message from b's queue, this 
would compromise the typing of b: the endpoint type associated with b is T2, but as we 
remove the message from its queue it turns to end. The b in the message, however, would 
retain the now obsolete type T%, with potentially catastrophic consequences. A closer look 
at the heap in the reduction above reveals that the problem lies in the cycle involving b: 
it is as if the b i-> [a,m(6)] region of the heap needs not be owned by any process because 
it "owns itself". With respect to other type systems for session types, we must tighten our 
typing rules and make sure that no cycle involving endpoint queues is created in the heap. 
In the process above this problem would not be too hard to detect, as the fact that a and b 



20 



V. BONO AND L. PADOVANI 



are peer endpoints is apparent from the syntax of the process. In general, however, a and b 
might have been acquired in previous communications (think of the f oo and bar functions 
in Section [21 where nothing is known about the arguments e and f save for their type) and 
they may not even be peers. For example, the process 

open(a : T\,c : T2).open(6 : T\,d : T2).a!m(d).&!m(c).(close(a) | close(6)) 

creates a leak with a cycle of length 2 even though no endpoint is ever sent over its own 
peer. 

Our approach for attacking the problem stems from the observation that infinite values 
(once the leak configuration has been reached the endpoint b above fits well in this category) 
usually inhabit recursive types and the endpoint type T2 indeed exhibits an odd form of 
recursion, as the recursion variable a occurs within the only prefix of Ti- Forbidding this 
form of recursion in general, however, would (1) unnecessarily restrict our language and 
(2) it would not protect us completely against leaks. Regarding (1), we can argue that 
an endpoint type T 2 = rec <x!m(a).end (which begins with an output action) would never 
allow the creation of cycles in the heap despite its odd recursion. The reason is that, if 
we are sending an endpoint b : T 2 over a : T 2 , then the peer of a must have the dual type 
T 2 = ?m(T2).end (which begins with an input action) and therefore must be different from b. 
Regarding (2), consider the following variation of the process P above 

Q = open(a : S±,b : 5 , 2).a!m(52)(6).close(a) (5-2) 

where 

5*i = !m(a)(lin a). end and 52 = ?m(a)(lin a). end . 

Once again, Si and S2 are dual endpoint types and process Q behaves correctly with 
respect to them. Notice that neither Si nor S2 is recursive, and yet Q yields the same kind 
of leak that we have observed in the reduction of P. 

What do T2 and S2 have in common that T 2 and Si do not and that makes them 
dangerous? First of all, both T2 and S2 begin with an input action so they denote endpoints 
in a receive state, and only endpoints in a receive state can have a non-empty queue. Second, 
the type of the arguments in T2 and S2 may denote other endpoints with a non-empty queue: 
in T2 this is evident as the type of the argument is T2 itself; in £2 the type of the argument 
is the existentially quantified type variable a, which can be instantiated with any endpoint 
type and, in particular, with an endpoint type beginning with an input action. If we think of 
the chain of pointers originating from the queue of an endpoint, we see that both T2 and S2 
allow for chains of arbitrary length and the leak originates when this chain becomes in fact 
infinite, meaning that a cycle has formed in the heap. Our idea to avoid these cycles uses 
the fact that it is possible to compute, for each endpoint type, a value in the set IN U {00}, 
that we call weight, representing the upper bound of the length of any chain of pointers 
originating from the queue of the endpoints it denotes. A weight equal to 00 means that 
there is no such upper bound. Then, the idea is to restrict the type system so that: 

Only endpoints having a finite-weight type can be sent as messages. 

A major issue in defining the weight of types is how to deal with type variables. If type 
variables can be instantiated with arbitrary endpoint types, hence with endpoint types 
having arbitrary weight, the weight of type variables cannot be estimated to be finite. At 
the same time, assigning an infinite weight to every type variable can be overly restrictive. 
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To see why, consider the following fragment of the MAP process defined in Example 14.11 

[• • -].source?Data(x : lin a) .mapper \krg{x) .[■ ■ ■] 

The process performs an output operation mapperlkrg(x) which, according to our idea, 
would be allowed only if the type of argument x had a finite weight. It turns out that x 
has type lin a and is bound by the preceding input action source?Data(x : lin a). If we 
estimate the weight to a to be infinite, a simple process like MAP would be rejected by 
our type system. By looking at the process more carefully one realizes that, since x has 
been received from a message, its actual type must be finite- weight, for otherwise the sender 
(the process using source's peer endpoint) would have been rejected by the type system. In 
general, since type variables denote values that can only be passed around and these must 
have a finite-weight type, it makes sense to impose a further restriction: 

Only finite-weight endpoint types can instantiate type variables. 

Then, in computing the weight of a type, we should treat its free and bound type variables 
differently: free type variables are placeholders for a finite-weight endpoint type and are 
given a finite weight; bound type variables are yet to be instantiated with some unknown 
endpoint type of arbitrary weight and therefore their weight cannot be estimated to be 
finite. We will thus define the weight ||i||A of a type t with respect to a set A of free type 
variables: 

Definition 5.1 (type weight). We say that W is a coinductive weight bound if (A, T, n) 
implies either: 

• T = end, or 

• T = a € A, or 

• T = {\mi(ai)(ti).Ti} ieI , or 

• T = {?mj(aj)(gj Si).Ti}i£i and n > and ctj $ A and (A, Si, n— 1) S W and (A, Tj, n) £ W 
for every i £ /. 

We write A h T :: n if (A, T, n) eW for some coinductive weight bound W. The weight of 
an endpoint type T with respect to A, denoted by ||T||a, is defined by ||T||a = min{n € INI | 
A h T :: n} where we let min0 = oo. We simply write ||T|| in place of ||T||0 and we extend 
weights to types so that \\q T\\ = ||T||. When comparing weights we extend the usual total 
orders < and < over natural numbers so that n < oo for every n € INI and oo < oo. 

The weight of t is defined as the least of its weight bounds, or oo if there is no such 
weight bound. A few weights are straightforward to compute, for example we have ||end|| = 
||{!mj(aj)(tj).Tj}j e /|| = 0. Indeed, the queues of endpoints with type end and those in a 
send state are empty and therefore the chains of pointers originating from them has zero 
length. A type variable a can have a finite or infinite weight depending on whether it 
occurs free or bound. So we have ||a||{«} = and ||a|| = oo. Note that ||a||{ a } = 
although a may be actually instantiated with a type that has a strictly positive, but finite 
weight. Endpoint types in a receive state have a strictly positive weight. For instance we 
have ||?m(end).end|| = 1 and ||?m(?m(end).end).end|| = 2. If we go back to the examples of 
endpoint types that we used to motivate this discussion, we have 1 1 7^ 1 1 = ll^ill = an d 
11^211 = II 52 II = oo, from which we deduce that endpoints with type T' 2 or Si are safe to be 
sent as messages, while endpoints with type T2 or S2 are not. 

Before we move on to illustrating the type system, we must discuss one last issue that 
has to do with subtyping. Any type system with subtyping normally allows to use a value 
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having type t where a value having type s with t ^ s is expected. For example, in the MAP 
process we have silently made the assumption that the value x received with the Data- 
tagged message had exactly the (finite-weight) type with which a has been instantiated 
while in fact x might have a smaller type. Therefore, the restrictions we have designed 
work provided that, if t ^ s and s is finite- weight, then t is finite-weight as well. This 
is indeed the case, and in fact we can express an even stronger correspondence between 
weights and subtyping: 

Proposition 5.1. t ^ s implies \\t\\& < ||s||a- 

Proof. It is easy to show that W = {(A, T, n) |3S:AhT^5&AhS::n}U {(A, t, n) \ 
3s : A h t ^ s & Ah s :: n} is a coinductive weight bound. □ 

5.2. Typing the Heap. The heap plays a primary role because inter-process communi- 
cation utterly relies on heap-allocated structures; also, most properties of well-behaved 
processes are direct consequences of related properties of the heap. Therefore, just as we 
will check well typedness of a process P with respect to a type environment that associates 
the pointers occurring in P with the corresponding types, we will also need to check that 
the heap is consistent with respect to the same environment. This leads to a notion of well- 
typed heap that we develop in this section. The mere fact that we have this notion does 
not mean that we need to type-check the heap at runtime, because well-typed processes 
will only create well-typed heaps and the empty heap will be trivially well typed. We shall 
express well- typedness of a heap \x with respect to a pair Vq; V of type environments where V 
contains the type of unrestricted pointers and the type of the roots of /i (the pointers that 
are not referenced by any other structure allocated on the heap), while Vq contains the type 
of the pointers to allocated structures that are reachable from the roots of \x. 

Among the properties that a well-typed heap must enjoy is the complementarity be- 
tween the endpoint types associated with peer endpoints. This notion of complementarity 
does not coincide with duality because of the communication model that we have adopted, 
which is asynchronous: since messages can accumulate in the queue of an endpoint before 
they are received, the types of peer endpoints can be misaligned. The two peers are guar- 
anteed to have dual types only when both their queues are empty. In general, we need to 
compute the actual endpoint type of an endpoint by taking into account the messages in 
its queue. To this end we introduce a tail(-, •) function for endpoint types such that 

tail(T,m(5)(s)) = T' 

indicates that a message with tag m, type argument S, and argument of type s can be 
received from an endpoint with type T which can be used according to type T 1 thereafter. 
The function is defined by the rule: 

k £ I s < t k {S/a k } 

ta.±l({?mi(ai)(ti).Ti}i e i,m k (S)(s)) = T k {S/a k } 

Note that tail(T, m{S)(s)) is undefined when T = end or T is an internal choice. 
This is consistent with the observation that it is not possible to receive messages from 
endpoints having these types. We extend tail(-, ■) to possibly empty sequences of message 
specifications thus: 

tail(r,e) = T 

tail(T,mi(5i)(si) • • • m n {S n )(s n )) = tail(tail(r,m 1 (5i)(s 1 )),m 2 (5 , 2)(s2) ■ • • m n (S' n )(s n )) 
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We now have all the notions to express the well-typedness of a heap \i with respect to 
a pair Vq;V of type environments. A type environment is a finite map F = {ui : qi Tj}j e j 
from names to types. We adopt the following notation regarding type environments: 

• We write dom(F) for the domain of F, namely the set {u^ \ i G /}; 

• we write V, V for the union of V and V when dom(F) n dom(r') = 0; 

• we write q(V) if q = % for every i G / and we say that F is linear if lin(T) and unrestricted 
if un(T); 

• we define the q-restriction of V as V\ q = {u,, : q Ti \ i G / &: qi = q}; 

• finally, we write F h u : t if F(u) = t. 

Definition 5.2 (well-typed heap). Let I i n ( To ) and dom(ro)ndom(T) = where every endpoint 
type in Vq, F is well formed. We write Vq; F h //if all of the following conditions hold: 

(1) For every a (->• [6, 0] G /i we have 6 h-> [a, £2'] G ^ and either a = b or £2 = e or £2' = e. 

(2) For every o h> [6,e] 6 ju and b \-t [a,mi(5i)(vi) ::•■■:: m n (S n )(v n )] G /J, with a 7^ b we 
have 

T = tail(5,mi(5i)(si) • • • m n (5„)(s n )) 
where Fo, V h o : lin T and Fo, T h 6 : lin 5 and Vq, V h Vj : Sj and max{||5j||, < 00 

for 1 < i < n. 

(3) For every a h-> [a,mi(5i)(vi) ::•••:: m n (5 n )(v n )] 6/iwe have 

T = tail(5,mi(5i)(si) • • • m n (5 n )(s n )) 

where Fo, F h a : un T and Fo, F h a : lin 5 and Fo, F h v« : si and max{||5i||, ||sj||} < 00 
for 1 < i < n. 

(4) dom(/i) = dom(Fo, F||j n ) = reach(dom(r), /i); 

(5) reach({a}, ;u) fl reach({&}, //) = for every a,b £ dom(r) with a 7^ 6. 

Condition (1) requires that in a well-typed heap every endpoint comes along with its 
peer and that at least one of the queues of peer endpoints be empty. This invariant is ensured 
by duality, since a well-typed process cannot send messages on an endpoint until it has read 
all the pending messages from the corresponding queue. Condition (2) requires that the end- 
point types of peer endpoints are dual. More precisely, for every endpoint a with an empty 
queue, the dual T of its type coincides with the residual tail(S', mi(S'i)(si) • • ■m n {S n )(s n )) 
of the peer's type S. Additionally, every Si and Sj has finite weight. Condition (3) is sim- 
ilar to condition (2), but deals with unrestricted endpoints. The only difference is that a 
has no peer endpoint, and the (unrestricted) dual endpoint type is associated instead with 
a. Condition (4) states that the type environment Vq, F must specify a type for all of the 
allocated objects in the heap and, in addition, every object (located at) a in the heap must 
be reachable from a root b G dom(F). Finally, condition (5) requires the uniqueness of the 
root for every allocated object. Overall, since the roots will be distributed linearly to the 
processes of the system, conditions (4) and (5) guarantee the ownership invariant, namely 
that every allocated object belongs to one and only one process. 

5.3. Typing Processes. First of all we define an operation on type environments to add 
new associations: 

{T if T h u : t and un(t) 

r, u : t if u G" dom(F) 
undefined otherwise 



24 V. BONO AND L. PADOVANI 



Table 8: Typing rules for processes. 



(T-Idle) (T-Close) 

un(r) un(r) 



L; A; V h L; A; P, w : lin end h close(u) 

(T-Open Linear Channel) (T-Open Unrestricted Channel) 

AlhT I;A;r,a : lin T,b : lin Th P A lh T I; A; V, a : lin T, a : un T h P 
I;A;P h open(a :T,b: T).P I; A; f h open(a : T).P 

(T-Send) 

AlhS 

fcG/ s^t k {S/ak} max{||S'||A, ||s||a} < oo I; A; T,u : q Tk{S/aif.} h P 
I; A; (r,« : q {Im^aj)^).^}^/) + v : s h u\vn k {S)(v).P 

(T-Receive) 

A lh (t£7) gj < tj (ieJ) I; A, aj; r, m : lin T i; g : h P, ^ 
I;A;r,u : lin {?mj(aj}(si).Pi} ie / h Eie/uJ ' u?m i( Q; i)( a; i : *i)-ft 

(T-Choice) (T-Par) 
I;A ; rhP I;A;rhQ IjAjTihP I;A ; r 2 hQ 
I;A;rhP0Q I;A;ri + r 2 hP|Q 

(T-Rec) (T-Var) 

(A;r)};A ; rhP dom(r|ir„) C fn(P) un(r') 



I; A; r h rec XP I, {X (A; f)}; A, A'; r.T'hl 



In plain words, an association u : t where t is linear can be added to V only if u does 
not already occur in V. An association u : t where t is unrestricted can be added to V in 
two cases: either u does not occur in F, in which case the association is simply added, or 
the same association already occurs in P, in which case the operation has no effect on the 
environment. In all the other cases the result is undefined. We generalize + to pairs of 
arbitrary environments V + V in the natural way. 

The typing rules for processes are inductively defined in Table El Judgments have the 
form Z; A; V h P and state that process P is well typed under the specified environments. 
The additional environment L is a map from process variables to pairs (A; V) and is used 
for typing recursive processes. We describe the typing rules in the following paragraphs: 

• Rule (T-Idle) states that the idle process is well typed in every unrestricted type envi- 
ronment. Since we impose a correspondence between the free names of a process and the 
roots of the heap, this rule states that the terminated process has no leaks. 

• Rule (T-Close) states that a process close(u) is well typed provided that u corresponds 
to an endpoint with type end, on which no further interaction is possible. Also, the 
remaining type environment must be unrestricted. 

• Rule (T-Open Linear Channel) deals with the creation of a new linear channel, which 
is visible in the continuation process as two peer endpoints typed by dual endpoint types. 
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The premise A lh T requires T to be well formed with respect to the type variables in A. 
In addition, the rule implicitly requires that no type variable, not even those in A, can 
occur at the top level in T, for otherwise its dual T would be undefined. 

• Rule (T-Open Unrestricted Channel) deals with the creation of a new unrestricted 
channel, which is accessible in the continuation process by means of two names: a is the 
linear pointer used for receiving messages while a is the unrestricted pointer used for send- 
ing messages. Note that T is qualified by 'un', therefore it must be T = {!mj(aj)(^).T}j g / 
and T = {?mi(ai)(ti).T} ie i. 

• Rule (T-Send) states that a process u\m{S)(v).P is well typed if u (which can be either 
linear or unrestricted according to q) is associated with an endpoint type T that permits 
the output of m-tagged messages (second premise). The endpoint type S instantiates the 
type argument of the message, while the type of the argument v must be a subtype of the 
expected type in the endpoint type where a has been instantiated with S (third premise). 
Both S and s must be finite- weight (fourth premise). Since the peer of u must be able to 
accept a message with an argument of type s, its weight will be strictly larger than that 
of s. This is to make sure that the the output operation does not create any cycle in the 
heap. Observe that the weights of S and s are computed with respect to the environment 
A, containing all the free type variables that can possibly occur in S and s. Finally, the 
continuation P must be well typed in a suitable type environment where the endpoint u 
is typed according to a properly instantiated continuation of T (fifth premise). Beware 
of the use of + in the type environments of the rule: if s is linear, then v is no longer 
accessible in the continuation P; if s is unrestricted, then v may or may not be available 
in P depending on whether P uses v again or not. Note also that every endpoint type 
occurring in the process is verified to be well formed with respect to A (first premise). 

• Rule (T-Receive) deals with inputs: a process waiting for a message from an endpoint 
u : q T is well typed if it can deal with at least all of the message tags in the topmost 
inputs of T. The continuation processes may use the endpoint u according to the endpoint 
type Ti and can access the message argument X{. The context A is enriched with the type 
variable on denoting the fact that Pi does not know the exact type with which aj has been 
instantiated. Like for the previous typing rule, there is an explicit premise demanding 
well-formedness of the types occurring in the process. 

• Rules (T-Choice) and (T-Par) are standard. In the latter, the type environment is split 
into two environments to type the processes being composed. According to the definition 
of +, Ti and V2 can only share associations with unrestricted types and, if they do, the 
associations in V\ and in I2 for the same name must be equal. 

• Rule (T-Rec) is a nearly standard rule for recursive processes, except for the premise 
dom(r||j n ) C fn(P) that enforces a weak form of contractivity in processes. It states 
that rec X.P is well typed under V only if P actually uses the linear names in dom(F). 
Normally, divergent processes such as rec X.X are well typed in every type environment. 
If this were the case, however, the process open(a : T,b : T).rec X.X, which leaks a and 
b, would be well typed. 

• We conclude with the familiar rule (T-Var) that deals with recursion variables. The rule 
takes into account the possibility that new type variables and (unrestricted) associations 
have accumulated in A and V since the binding of X. 

Systems (/1; P) are well typed if so are their components: 

Definition 5.3 (well-typed system). We write Fq; V h (fJ-;P) if Rj; V h fi and V h P. 
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Let us present the two main results about our framework: well-typedness is preserved by 
reduction, and well-typed processes are well behaved. Subject reduction takes into account 
the possibility that types in the environment may change as the process reduces, which is 
common in behavioral type theories. 

Theorem 5.1 (subject reduction). Let Vq;V h (/x; P) and (/u;P) — > Then Fq; F' h 

(fi')P') for some Tq and V . 

Theorem 5.2 (safety). Let h P. Then P is well behaved. 



5.4. Examples. We conclude this section with a few extended examples: the first one is 
meant to show a typing derivation; the second one presents a scenario in which it would 
be natural to send around endpoints with infinite weight, and shows a safe workaround to 
circumvent the finite-weight restriction; the last example demonstrates the expressiveness 
of our calculus in modeling some advanced features of Sing*, namely the ability to safely 
share linear pointers between several processes. 

Example 5.1 (forwarder). We illustrate a type derivation for a simple forwarder process 
that receives two endpoints with dual types and forwards the stream of m-tagged messages 
coming from the first endpoint to the second one. We have at least two ways to implement 
the forwarder, depending on whether the stream is homogeneous (all the m-tagged messages 
carry an argument of the same type) or heterogeneous (different m-tagged messages may 
carry arguments of possibly different types). Considering the latter possibility we have: 

FWD(a) = a?Src(a; : lin T).a?Dest(y : lin T). 

(close(a) | rec X.x?m(a)(z : lin a).y\m(a)(z).X) 

where 

T = rec /3.?m(a)(lin a)./3 . 
Below we show the derivation proving that FWD is well typed. To keep the derivation's 
size manageable, we elide some subprocesses with [ • • • ] and we define F = x : lin T, y : lin T. 

(T-Var) 



f^« r » ! ° ;r " (T-Send) 



{X ^ (t»;r)};a;r,z ah y<m( a )(z).X 

(T - Cl o SE ) (-^wn};ftr^w( g :iina).[-][ T ; > 

a : lin end h close(a) x : lin T, y : lin T h rec X.\ ■ ■ ■ 1 . 

— = - - (T-Par) 

a : lin end, x : lin T, y : lin T h close(a) I rec X.\ ■ ■ ■ 1 

■ = — — = — — (T- Receive) 

a : lin ?Dest(lin T).end, x : lin T h a?Dest(y : lin T).[ ■ • • ] : ' 

(T-Receive) 

a : lin ?Src(lin T).?Dest(lin T).end h FWD (a) 

Observe that, by the time rule (T-Var) is applied for the process variable X, a type variable 
a has accumulated into the bound type variables context which was empty when X was 
introduced in (T-Rec). Therefore, it is essential for rule (T-Var) to discharge extra type 
variables in the bound type variable context for declaring this process well typed. ■ 

Example 5.2 (linear lists). In most of the examples we have presented so far the type of 
services begins with an output action, suggesting that it is the consumers of these services 
that play the first move and invoke them by sending a message. There are cases, in particular 
with the modeling of datatypes, where it is more natural to adopt the dual point of view, 
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in which the reception of a message indicates the consumption of the data type. In this 
example we represent a linear list as an endpoint from which one of two kinds of messages 
can be received: a Nil-tagged message indicates that the list is empty; a Cons-tagged 
message indicates that the list has at least one element, and the parameters of the message 
are the head of the list and its tail, which is itself a list. Reading a message from the 
endpoint corresponds to deconstructing the list and the tag-based dispatching of messages 
implements pattern matching. Along these lines, the type of lists with elements of type a 
would be encoded as the endpoint type 

List(a) = rec /3.(?Nil().end + ?Cons(lin a, lin /3).end) 

Note that, just as this type denotes lists of arbitrary length, the encoding of lists in 
terms of messages within endpoints may yield chains of pointers of arbitrary length because 
of the recursion of f3 through an input prefix. As a consequence we have ||List(a)||{ Q } = 
oo, meaning that our type system would reject any output operation sending a list over 
an endpoint. Incidentally, since a non-empty list is encoded as a Cons-tagged message 
containing another list, the finite- weight restriction on the type of message arguments would 
in fact prevent the construction of any non-trivial list, rendering the type List(a) useless. 

It is possible to fix this by requiring the consumers of the list to signal the imminent 
deconstruction via a "prompt" message. This corresponds to defining 

List(a) = rec /3.!Prompt().(?Nil().end + ?Cons(lin a, lin /3).end) 

The insertion of an output action between the binding of f3 and its occurrence among 
the arguments of Cons nullifies the weight of List(a), that is ||List(a)||{ a } = 0. To see 
why this is sufficient for preventing the creation of cycles in the heap consider a process 

6!Cons(x, a).P 

where we assume that a : List(a) and b : !Nil().end © !Cons(lin a, List(a))). The intention 
here is to yield a leak like the one generated by the process in (15. ip . Note however that the 
peer endpoint of b must have already been used for sending the Prompt-tagged message, 
while a has type List(a) and therefore no Prompt-tagged message has been sent on a yet. 
We conclude that a cannot be 6's peer. 

As an example of list-manipulating function we can now define the polymorphic consing 
service on channel c, that creates a list from a head and a tail, thus: 

CONS(c) = rec Xc? Invoke (a) (x : lin T). 

x?Arg(y : lin a).xlkrg{z : lin List(a)). 
open(a : List(a),6 : List(a)). 
(6?Prompt().fo!Cons(y, z).close(b) \ xlres(a).X) 

where 

T = ?Arg(lin a).?Arg(lin List(a)).!Res(lin List(a)).end 
The interested reader can verify that 

c : rec /3.?Invoke(a)(lin T).(3 h CONS(c) 
is derivable. ■ 

Example 5.3. Development of the Singularity OS prototype has suggested that there 
are many scenarios in which the ownership invariant, requiring that a given object - an 
endpoint - can be owned exclusively by one sole process at any given time, easily leads 
to convoluted code. For this reason, Sing* provides a TCell<a> class that permits the 
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Table 9: Modeling of a shared mutable cell. 


MKCELL(a) 


= a: Invoke(a)(x : hn !Res(un i T ceii(a)).endj. 




open(c : T T c e ii(a)).open(buffer : r Buff er(a))- 




opeiL(acquire : T kcquiie (a)).open(release : T Release (a)). 




x!Res(c).(EMPTY(a, c) close(x) MKCELL(a)) 


EMPTY(a, c) 


= c.'Invoke(x : hn J ). 




( x?Acquire().acgmre!ln(x).EMPTY(a, c) 




+ x:Release().a;!0k().2;:Arg(?/ : hn a). 




• n / • \ > i / 7 PC | T / \ 1 — i / \ 1 i — it xt t / \ \ 

if empty (acquire ) then (buffer ]In(y) close(a;J t ULL(a, c)) 




else acquire?In(z : lin !Res(lin a).end).z!Res(y). 




(close(x) | close(z) EMPTY(a,c))) 


FULL(a,c) 


= c:Invoke(2; : hn i ). 




( x?Acquize(). buff er?In(y : lin a).x!Res(?/). 




if empty (release) then (close(x) EMPTY(a,c)) 




else release 1\ti(z : hn !0k(). :Res(hn a). end). 




1 f \ o« / i" \ 7 pc i-r/\ 

z!0k().z:Arg(y : hn a).buffer\Iii(y). 




( -I / \ 1 -t / \ 1 -PTTT T / \\\ 

(close(x) closed) b ULL(a,c))) 




1 (In i / \ 7 1 _ / \ -1 — IT TT T / \ \ 

+ ccrReleaseO.raeaselln^x).! 1 ULL(a, c)) 


T(a) 


= ?Acquire().!Res(lin a). end + ?Release().!Ok().?Arg(lin a). end 


TTCell(a) 


= rec /3.?Invoke(lin T(a)).(3 


^Buffer {&) 


= rec /3.?In(lin a). (3 


^Acquire (a) 


= rec /3.?In(lin !Res(lin a).end)./3 


^Release («) 


= rec /3.?In(lin !0k().?Res(lin a). end)./? 



unrestricted sharing of exchange heap pointers at the expense of some runtime checks. In 
practice, an instance of TCell<a> acts like a 1-place buffer for a linear pointer of type a and 
can be shared non-linearly among different processes. A process willing to use the pointer 
must explicitly acquire it, while a process that has finished using the pointer must release 
it. The internal implementation of TCell<a> makes sure that, once the pointer has been 
acquired, all subsequent acquisition requests will be blocked until a release is performed. 
The interface of TCell<a> is as follows: 

class TCell<a> { 

TCell( [Claims] a in ExHeap) ; 

a in ExHeap Acquire () ; 

void Release( [Claims] a in ExHeap); 

} 

Table [9] presents an implementation of the Sing* class TCell<a> in our process calculus. 
For readability, we have defined the MKCELL(a) process in terms of (mutually) recursive 
equations that can be folded into a proper term as by [7]. Below we describe the process 
from a bird's eye point of view and expect the reader to fill in the missing details. 

MKCELL(a) waits for invocations on endpoint a. Each invocation creates a new cell 
represented as a linear endpoint c (retained by the implementation) and an unrestricted 
pointer c (that can be shared by the users of the cell). The cell consists of three unrestricted 
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endpoints: buffer is the actual buffer that contains the pointer to be shared, while acquire 
and release are used to enqueue pending requests for acquisition and release of the cell 
content. The implementation ensures that buffer always contains at most one message (of 
type a), that acquire can have pending requests only when buffer is empty, and that release 
can have pending requests only when buffer is full. Users of the cell send invocation requests 
on endpoint c. When the cell is empty, any acquisition request is enqueued into acquire 
while a release request checks whether there are pending acquisition requests by means of 
the empty (acquire) primitive: if there is no pending request, the released pointer y is stored 
within buffer and the cell becomes full; if there are pending requests, the first one (z) is 
dequeued and served, and the cell stays empty. When the cell is full, any release request 
is enqueued into release while the first acquisition request is served immediately. Then, 
the cell may become empty or stay full depending on whether there are pending release 
requests. 

One aspect of this particular implementation which is highlighted by the endpoint type 
T(a) is the handling of multiple release requests. In principle, it could be reasonable for 
the Release-tagged message to carry an argument of type a, the pointer being released. 
However, if this were the case a process releasing a pointer would immediately transfer 
the ownership of the pointer to the cell, even in case the cell is in a full state. This 
is because communication is asynchronous and send operations are non-blocking, so the 
message with the pointer would be enqueued into release, which is permanently owned by 
the cell, regardless of whether the cell is already full. In our modeling, the Release-tagged 
message carries no argument, its only purpose being to signal the intention for a process to 
release a pointer. If the cell is empty, then the cell answers the requester with an Ok-tagged 
message, and only at that point the pointer (and its ownership) is transferred from the 
requester to the cell with an Arg-tagged message. If however the cell is full when the release 
request is made, the Ok-tagged message is deferred and the requester remains the formal 
owner of the pointer being released until the cell becomes empty again. ■ 

6. Algorithms 

In this section we define algorithms for deciding subtyping and for computing the weight of 
(endpoint) types. We also argue how the typing rules in Table [8] can be easily turned into 
a type checking algorithm using a technique explained elsewhere. 

6.1. Subtyping. The algorithm for deciding the subtyping relation T ^ S is more easily 
formulated if we make a few assumptions on the variables occurring in T and S. The reason 
is that ^ (Definition 13. 2p implicitly uses alpha renaming in order to match the bound type 
variables occurring in one endpoint type with the bound type variables occurring in the 
other endpoint type. However, termination of the subtyping algorithm can be guaranteed 
only if we perform these renamings in a rather controlled way, and the assumptions we are 
going to make are aimed at this. 

Definition 6.1 (independent endpoint types). We say that T and S are independent if: 

(1) ftv(T) nbtv(T) = 0; 

(2) ftv(S) Dbtv(S) = 0; 

(3) no type variable in T or in S is bound more than once; 

(4) btv(T) n btv(5) = 0. 
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Table 10: Algorithmic subtyping rules. 



(S-Var) (S-End) 

y h m a 4 a & l~m end ^ a end 



(S- Axiom) 

(t, s)^y 



(S-Rec Left) 

J?* U {(rec a.T, S)} h m T{rec a.T/a} ^ a 5 
=5" h m rec a.T ^ a 5 



(S-Rec Right) 

y U {(T, rec a.S)} H m T ^ a 5{rec a.S/a) 



(S-Type) 



lT^ a q' S 



l~m T ^ a rec ct.S 



(S-Input) 



^' = yu{(T,S)} ICJ y'h m f ! {m(a i ,ft)/ a! }4s l {m(a !) ft)/A} ( '' e/) 
y' Hm T{m(a,,A)/aa ^ 3 ,g,{m(a,, &)/&} ^ 

y h m T = {?m i (ai>(*i).r i } i6 / ^ a {?ny(&0(*i)-Sj}j6J = 5 



J^' = J^U{(T,S)} JCJ ^" h m 8j{m{aj^, )/&} ^ a t i {m(a i , (ieJ) 

g 7}{m(n ; . j,-).n,-} ^ 3 S J {m(a j , ft)/^} ^' eJ > 

y h m T = {Im^)^).^}^ ^ a {!m ; : ^(a;).^-},-, = S 



Informally, conditions (1-3) state that T and S obey the so-called Barendregt conven- 
tion for type variables, by stating that free and bound type variables are disjoint and that 
every type variable is bound at most once. Condition (4) makes sure that there is no shared 
bound type variable between T and S. 

We will restrict the subtyping algorithm to independent endpoint types. This is bear- 
able as every pair of endpoint types can be easily rewritten into an equivalent pair of 
independent endpoint types: 

Proposition 6.1. For every T and S there exist independent T' and S' such that T = T' 
and S = S' . 

Proof sketch. A structural induction on T followed by a structural induction on S, in both 
cases renaming bound variables with fresh ones. □ 

The subtyping algorithm is defined using the rules in Table [TUl thus: 

Definition 6.2 (subtyping algorithm). Let T and S be independent endpoint types. Let 
m be a map from unordered pairs of type variables to type variables such that m(a, /3) 
ftv(T) U btv(T) U ftv(S) U btv(S) for every a £ btv(T) and /3 € btv(S). We write 
h m T < a 5 if and only if0H m T^ a 5is derivable with the axioms and rules in Table QUI 
where we give rule (S-Axiom) the highest priority, followed by rule (S-Rec Left), followed 
by rule (S-Rec Right), followed by all the remaining rules which are syntax-directed^ 

^The relative priority of rules (S-Rec Left) and (S-Rec Right) is irrelevant since they are confluent. 



(S-Output) 
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The algorithm derives judgments of the form 3* h m T ^ a S, where 3" is a memoization 
context that records pairs of endpoint types that are assumed to be related by subtyp- 
ing. The map m is used for unifying consistently the bound type variables of the endpoint 
types being related. The same (unordered) pair of bound type variables (a, (3) is always 
unified to the same fresh type variable m(a,/3), which is essential for guaranteeing that the 
memoization context 3* does not grow unwieldy. The fact that we work with unordered 
pairs simply means that m(a,/3) = m(/3,a) for every a £ btv(T) and (3 £ btv(S). The 
axioms and rules in Table [TU] are mostly unremarkable, since they closely mimic the coin- 
ductive definition of subtyping (Definition I3.2|) , therefore we only comment on the peculiar 
features of this deduction system: Axiom (S-Axiom) allows one to immediately deduce 
y h m T ^ a S whenever the pair (T, S) occurs in 3* . This prevents the algorithm to loop 
forever when comparing recursive endpoint types. A pair (T, S) is added to 3* whenever a 
constructor is crossed, which happens in rules (S-Rec Left), (S-Rec Right), (S-Input), 
and (S-Output). Rules (S-Rec Left) and (S-Rec Right) unfold recursive endpoint 
types in order to expose their outermost proper constructor (an internal/external choice 
or end). Contractivity of endpoint types guarantees that a finite number of applications of 
these rules is always enough to achieve this exposure. In Definition 13.21 recursive endpoint 
types are not treated explicitly since equality '=' is defined modulo folding/unfolding of 
recursions. Rules (S-Input) and (S-Output) deal with inputs and outputs. Note that the 
pairs of endpoint types being compared in the conclusions of the rules have distinct sets 
{ai}i<zi and {(3j}j € j of bound type variables that are unified in the premises by means of 
the map m. 

The following result establishes the correctness and completeness of the subtyping al- 
gorithm with respect to ^ for independent endpoint types. 

Theorem 6.1 (correctness and completeness). Let Tq and Sq be independent endpoint types 
and m be a map as by Definition ] 6. Then h m To ^ a Sq if and only if Tq ^ Sq. 

Example 6.1. Consider the endpoint types 

T = rec a.!a(ai)(!b(a 2 )(a 2 ).ai).a 

S = rec /3.!a(/3 1 )(!b(/3 2 )(/3 2 )./3 1 ©!c(/3 3 )(/33).end)./3 

and observe that they are independent. The following derivation, together with Theo- 
rem [fTTJ shows that T ^ S: 

(S-Var) (S-Var) 



y3hm72472 ^ m7l ^ a7l (s _ 0uTpuT) (S , AxiOM) 



^2 !b(/3 2 )(/3 2 )-7i 9 !c(/3 3 )Q3 3 ).end s: a !b(q 2 )(q 2 ). 7l v ' Y 2 ^ m T^ a S 

h m !a(a 1 )(!b(a 2 )(a 2 ).q 1 ).r ^ a !a(/3 1 )(!b(/3 2 )(/3 2 )./j 1 !c(/? 3 )(/3 3 ).end).,S [ ~ R JL 

{(r,g)}h m !a(a 1 )(!b<a 2 )(a 2 ).q 1 ).r< a S „ ' 
0hmr<a5 (S-Rec Left) 

where we have used the abbreviations: 

• 7l = m(ai,/3i) and 72 = m(a 2 ,/3 2 ); 

• ^i = {(r,5),(!a(ai>(!b(a 2 )M.ai)-r,5)}; 

• j> 2 = S\ U {(!a<ai)(!b(a 2 )(a 2 ).ai).r, !a(/3 1 )(!b(/3 2 )(/3 2 )./3 1 © !c(/3 3 )(/3 3 ).end).S)}; 

• ^ 3 = y 2 U {(!b(/3 2 )(/3 2 ). 7l !c(/3 3 )(/3 3 ).end, !b(a 2 )(a 2 ). 7l )}. ■ 
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6.2. Type Weight. We now address the computation of the weight of an (endpoint) type, 
which is the least of its weight bounds or oo if it has no weight bound. Unlike the definition 
of weight bound (Definition l5.ip . the algorithm avoids unfoldings of recursive endpoint types 
in order to terminate. This imposes a refinement in the strategy we use for weighing type 
variables. Recall that, according to Definition 15.11 when determining ||T||^ type variables 
are weighed either or oo according to whether they occur in the context Ao or in btv(T) 
when they are bound in an input or output prefix. If we avoid unfoldings of recursions, we 
must also deal with type variables that are bound by recursive terms rec a.T. The idea is 
that these variables must be weighed differently, depending on whether they occur within 
an input prefix of T or not. For this reason, we use another context A that contains the 
subset of type variables bound by a recursive term and that can be weighed 0. 

Ultimately, we define a function W(Aq, A, T) by induction on the structure of T, thus: 



The first and fourth equations give a null weight to end and endpoint types in a send 
state, as expected. The third equation weighs a recursive term rec a.T by weighing the 
body T and recording the fact that a can be given a null weight, as long as a does not occur 
in a prefix of T. The second equation weighs a type variable a: if a occurs in Ao U A, then 
it means that either a occurs free in the original endpoint type being weighed and therefore 
must be given a null weight, or a is bound in a recursive term rec a. S but it does not occur 
within an input prefix of S; if a does not occur in Ao U A, then it means that either a was 
bound in an prefix of an endpoint type in send/receive state, or it was bound in a recursive 
term rec a. S and it occurs within an input prefix of S. The fifth equation determines the 
weight of an endpoint type in receive state. The rule essentially mimics the corresponding 
condition of Definition 15.11 but notice that when weighing the types t j in the prefixes the 
context A is emptied, since if any of the type variables in it is encountered, then it must 
be given an infinite weight. The last equation simply determines the weight of a qualified 
endpoint type to be the weight of the endpoint type itself. 

We work out a few simple examples to help clarifying the algorithm: 

• W(0, 0, ?m(a)(end).end) = max{l + W(0, 0, end), W(0, 0, end)} = 1; 

• W(0,0,?m(a)(a).end) = max{l + W(0, 0, a), W(0, 0, end)} = oo; 

• W(0,0,rec a.?m(a).end) = W(0, {a}, ?m(a).end) = max{l + W(0, 0, a), W(0, {a}, end)} = oo; 

• W(0,0,rec a.?m(end).a) = W(0, {a}, ?m(end).a) = maxjl + W(0, 0, end), W(0, {a}, a)} = 1. 

In the last example, note that the type variable a that virtually represents the recursive 
term rec a.T is weighed even though the whole term turns out to have weight 1. The 
idea is that the proper weight of the whole term will be computed anyway according to 
the structure of the term in which a occurs, and therefore we can safely approximate the 
weight of a to 0. This property of the algorithm, which is also one of the key ingredients 
for proving its correctness, can be formalized as the fact that the weight of a recursive term 
and of its unfolding are the same: 



W(A , A, end) 








W(A , A, rec a.T) 
W(Ao,A,{!mi(a;)(ti).7i}i e /) 
W(A ,A,{?m i (ai)(t i ).7-,} ie/ ) 
W(A ,A,(/T) 



W(A ,AU{a},T) 


max{l + W(A , 0, U), W(A , A \ {a*}, Tj)} ieI 
W(A ,A,T) 
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Proposition 6.2. W(A o ,0,rec a.T) = W(A , 0, T{rec a.T/a}). 

We conclude with the formal statement saying that the algorithm for computing weights 
is correct. Its termination is guaranteed as it works by structural induction over finite terms. 

Theorem 6.2. ||T|| A = W(A, 0, T). 

6.3. Type Checking. In Sections 16.11 and 16.21 we have already presented algorithms for 
deciding whether two (endpoint) types are related by subtyping and for computing the 
weight of (endpoint) types. Therefore, there is just one aspect left that makes the type 
checking rules in Table [8] non-algorithmic, which is the decomposition of the type environ- 
ment T into Pi + Y% when attempting to derive the judgment L; A; V h P \ Q by means of 
rule (T-Par). The idea is to look at the free names of P and Q that have linear types 
in P and to split V in such a way that dom(Ti|ii n ) C fn(P) and dom(r 2 ||j n ) C fn(Q) and 
dom(ri| un ) = dom(T2| un ) = dom(r| un ). Clearly, if P and Q share a free name that has a linear 
type in V there is no way to derive the judgment L; A; V h P \ Q. We omit a formal definition 
of this splitting since it can be worked out precisely as explained in |10j . 

7. Related work 

Singularity OS. Copyless message passing is one of the key features adopted by the Sin- 
gularity OS [15] to compensate the overhead of communication-based interactions between 
isolated processes. Communication safety is enforced by checking processes against channel 
contracts that are deterministic, autonomous, and synchronizing \21\ I24j . A contract is 
deterministic if there cannot be two transitions that differ only for the target state, au- 
tonomous if every two transitions departing from the same state are either two sends or 
two receives, and synchronizing if every loop that goes through a final state has at least one 
input and one output action. As argued in [8], session types can model channel contracts 
quite well because they always correspond by construction to contracts that are determin- 
istic and autonomous. Session types like those adopted in this work have just one final 
state end and therefore are trivially synchronizing, but this implies that we are unable to 
model contracts where a final state has outgoing transitions. This is not an intrinsic limit 
of session types (it is possible to extend session types with more general "final states" as 
shown in [5]) and plausibly this restriction is quite natural in practice (for example, all the 
channel contracts in the source code of Singularity OS have final states without outgoing 
transitions). 

Interestingly, already in [S] it was observed that special attention must be deserved to 
the type of endpoints that are sent as messages to avoid inconsistencies. In Singularity OS, 
endpoints (as well as any other memory block) allocated in the exchange heap are explicitly 
tagged with the identifier of their owner process, and when a block changes owner (because 
its pointer is sent in a message) it is the sender's responsibility to update the tag with the 
identifier of the receiver process. If this update is not performed atomically (and it cannot 
be, for efficiency reasons) the following can happen: a process sends a message m on an 
endpoint a whose peer b is owned by some process Pi; the sender therefore tags m with 
Pi; simultaneously, Pi sends b away to some other process P2; message m is now formally 
owned by Pi, while in fact it is enqueued in an endpoint that is owned by P2. The authors 
of [8] argue that this inconsistency is avoided if only endpoint in a "send state" (those whose 
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type begins with an internal choice) can be sent as messages. The reason is that, if 6 is in a 
"send state", then a, which must have a dual type, is in a "receive state", and therefore it is 
not possible to send message m on it. In this respect, our work shows that the "send state" 
restriction has deeper motivations that go beyond the implementation details of ownership 
transfer, it gives formal evidence that the restriction devised in [8] is indeed safe, because 
endpoints in a "send state" always have a null weight, and it shows how to handle a more 
expressive type system with polymorphic endpoint types. 

Early Type-Theoretic Formalizations of Singularity OS. This work improves pre- 
vious formalizations of Singularity OS presented in [21 [3]. The main differences regard 
polymorphic and unrestricted endpoint types and the modeling of Singh's expose. 

Polymorphic endpoint types increase the flexibility of the type system and are one of 
the features of Singularity OS, in the form of polymorphic contracts, documented in the 
design note dedicated to channels [IB]. The most interesting aspect of polymorphic endpoint 
types is their interaction with the ownership invariant (see the example (I5.2p ) and with the 
computation of type weights. Polymorphism was not considered in [2], and in [3] we have 
introduced a bounded form of polymorphism, along the lines of [S], but we did not impose 
any constraint on the instantiation of type variables without bound which were all estimated 
to have infinite weight. This proved to be quite restrictive (a simple forwarder process like 
the one in Example 15.11 would be ill- typed) . The crucial observation of the present type 
system is that type variables denote "abstract" values that can only be passed around. So, 
just as values that are passed around must have a finite-weight type, it makes sense to 
impose the same restriction when instantiating type variables. For the sake of simplicity, 
in the present work we have dropped type bounds for type variables. This allowed us to 
define the subtyping algorithm as a relatively simple extension of the standard subtyping 
algorithm for session types [TU]. It should be possible to work out a subtyping algorithm 
for bounded, polymorphic, recursive endpoint types, possibly adapting related algorithms 
defined for functional types IS], although the details might be quite involved. 

In [21 [3] only linear endpoint types were considered. However, as pointed out by some 
referees, a purely linear type system is quite selective on the sort of constructs that can 
be effectively modeled with the calculus. For this reason, in the present version we have 
introduced unrestricted endpoint types in addition to linear ones, with the understanding 
that other kinds of unrestricted data types (such as the primitive types of boolean or integer 
values) can be accommodated just as easily. We have shown that unrestricted endpoint types 
can be used for representing the type of non-linear resources such as permanent services 
and functions and we have also been able to implement the TCell type constructor of Sing* 
(Example 15. 3p . Interestingly, the introduction of unrestricted endpoint types required very 
little change to the process language (only a different open primitive) and no change at all 
to the heap model. 

The remaining major difference between [2] and this work is the lack of any expose 
primitive in the process calculus, which is used in the Sing* compiler to keep track of 
memory ownership. To illustrate the construct, consider the code fragment 

expose (a) { 
b.ArgOa) ; 

*a = new[ExHeap] T() ; 

} 
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which dereferences a cell a and sends its content on endpoint b. After the b.Arg(*a) 
operation the process no longer owns *a but it still owns a. Therefore, the ownership 
invariant could be easily violated if the process were allowed to access *a again. To prevent 
this, the Sing* compiler allows (linear) pointer dereferentiation only within expose blocks. 
The expose (a) block temporarily transfers the ownership of *a from a to the process 
exposing a and is well-typed if the process still owns *a at the end of block. In this example, 
the only way to regain ownership of *a is to assign it with the pointer to another object 
that the process owns. In [2J we showed that all we need to capture the static semantics 
of expose blocks is to distinguish cells with type *t (whose content, of type t, is owned 
by the cell) from cells with type *• (whose content is owned directly by the process). At 
the beginning of the expose block, the type of a turns from *t to *•; within the block it is 
possible to (linearly) use *a; at the end of the block, *a is assigned with the pointer to a 
newly allocated object that the process owns, thus turning a's type from *• back to some 
*s. In other words, cell types (and other object types) are simple behavioral types that can 
be easily modeled in terms of polymorphic endpoint types. In [3J we have shown that the 
endpoint type 

CellT = rec a.(!Set(/3)(lin /3).?Get(lin /3).a !Free().end) 

corresponds to the open cell type *• that allows for setting a cell with a value of arbitrary 
type and for freeing the cell. Once the cell has been set, its type turns to some 

?Get(t).CellT 

corresponding to the cell type *t that only allows for retrieving its content. The cell itself 
can be easily modeled as a process that behaves according to CellT, as shown in [3J. 

As a final note, in [2] we have shown how to accommodate the possibility of closing 
endpoints "in advance" (when their type is different from end), since this feature is available 
in Sing*. Overall, it seems like the issues it poses exclusively concern the implementation 
details rather than the peculiar characteristics of the formal model. Consequently, we have 
decided to drop this feature in the present paper. 

Type Weight. Other works [H[TT] introduce apparently similar, finite-size restrictions on 
session types. In these cases, the size estimates the maximum number of enqueued messages 
in an endpoint and it is used for efficient, static allocation of endpoints with finite-size type. 
Our weights are unrelated to the size of queues and concern the length of chains of pointers 
involving queues. For example, in [11] the session type T = rec a.?m(lin a). end has size 
1 (there can be at most one message of type lin T in the queue of an endpoint with type 
T) and the session type S = rec a.?m(lin end). a has size oo (there can be any number of 
messages, each of type lin end, in the queue of an endpoint with type S). In our theory 
we have just the opposite, that is ||T|| = oo and ||5|| = 1. Despite these differences, the 
workaround we have used to bound the weight of endpoint types (Example 15. 2|) can also be 
used to bound the size of session types as well, as pointed out in [llj . 

Logic-Based Analysis. A radically different approach for the static analysis of Singularity 
processes is given by [Ml ES] , where the authors develop a proof system based on a variant 
of separation logic [19]. The proof system permits the derivation of Hoare triples of the form 
{^4} P {B} where P is a program and A and B are logical formulas describing the state of 
the heap before and after the execution of P. A judgment {emp} P {emp} indicates that 
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if P is executed in the empty heap (the pre-condition emp), then it leaks no memory (the 
post-condition emp). However, leaks in [23] manifest themselves only when both endpoints 
of any channel have been closed. In particular, it is possible to prove that the function f oo 
in Section [2J is safe, although it may indeed leak some memory. This problem has been 
subsequently recognized and solved in [23]. Roughly, the solution consists in forbidding 
the output of a message unless it is possible to prove (in the logic) that the queue that is 
going to host the message is reachable from the content of the message itself. In principle 
this condition is optimal, in the sense that it should permit every safe output. However, 
it relies on the knowledge of the identity of endpoints, that is a very precise information 
that is not always available. For this reason, [23] also proposes an approximation of this 
condition, consisting in tagging endpoints of a channel with distinct roles (basically, what 
are called importing and exporting views in Singularity). Then, an endpoint can be safely 
sent as a message only if its role matches the one of the endpoint on which it is sent. This 
solution is incomparable to the one we advocate - restricting the output to endpoints with 
finite-weight type - suggesting that it may be possible to work out a combination of the 
two. In any case, neither [24] nor [23] take into account polymorphism. 

Global Progress. There exist a few works on session types [U [5] that guarantee a global 
progress property for well-typed systems where the basic idea is to impose an order on 
channels to prevent circular dependencies that could lead to a deadlock. Not surprisingly, 
the critical processes such as (15. ID that we rule out thanks to the finite-weight restriction on 
the type of messages are ill typed in these works. It turns out that a faithful encoding of (15. ip 
into the models proposed in these works is impossible, because the open(-, •) primitive we 
adopt (and that mimics the corresponding primitive operation in Singularity OS) creates 
both endpoints of a channel within the same process, while the session initiation primitives 
m [HE] associate the fresh endpoints of a newly opened session to different processes running 
in parallel. This invariant - that the same process cannot own more than one endpoint of 
the same channel - is preserved in well-typed processes because of a severe restriction: 
whenever an endpoint c is received, the continuation process cannot use any endpoint other 
than c and the one from which c was received. 

8. Conclusions 

We have defined the static analysis for a calculus where processes communicate through 
the exchange of pointers. Verified processes are guaranteed to be free from memory faults, 
they do not leak memory, and do not fail on input actions. Our type system has been 
inspired by session type theories. The basic idea of session types, and of behavioral types 
in general, is that operating on a (linearly used) value may change its type, and thus the 
capabilities of that value thereafter. Endpoint types express the capabilities of endpoints, 
in terms of the type of messages that can be sent or received and in which order. We have 
shown that, in the copy less message passing paradigm, linearity alone is not enough for 
preventing memory leaks, but also that endpoint types convey enough information - their 
weight - to devise a manageable type system that detects potentially dangerous processes: 
it is enough to restrict send operations so that only endpoint with a finite- weight type can be 
sent as messages and only finite-weight endpoint types can instantiate type variables. This 
restriction can be circumvented in a fairly easy and general way at the cost of a few extra 
communications, still preserving all the nice properties of the type system (Example 15. 2J . 
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We claim that our calculus provides a fairly comprehensive formalization of the peculiar 
features of Sing*, among which are the explicit memory management of the exchange heap, 
the controlled ownership of memory allocated on the exchange heap, and channel contracts. 
We have also shown how to accommodate some advanced features of the Sing* type sys- 
tem, namely (the lack of) [Claims] annotations, the TCell type constructor that allows 
for the sharing of linear pointers, and polymorphic channel contracts. In prior work [3] we 
had already shown how polymorphic endpoint types permit the encoding of expose blocks 
for accessing linear pointers stored within other objects allocated on the exchange heap. 
Interestingly, previous studies on Singularity channel contracts [8] had already introduced 
a restriction on send operations so that only endpoints in a send-state, those whose type 
begins with an internal choice, can be safely sent as messages. There the restriction was mo- 
tivated by the implementation of ownership transfer in Singularity, where it is the sender's 
responsibility to explicitly tag sent messages with their new owner. We have shown that 
there are more reasons for being careful about which endpoints can be sent as messages 
and that the send-state restriction is a sound approximation of our finite-weight restriction, 
because endpoints in a send-state always have a null weight. 

On a more technical side, we have also developed a decidable theory of polymorphic, 
recursive behavioral types. Our theory is incomparable with that developed in [9j: we 
handle recursive behavioral types, whereas [9] only considers finite ones; polymorphism 
in [9] is bounded, while it is unrestricted in our case. The subtyping relation that takes 
into account both recursive behaviors and bounds is in fact quite straightforward to define 
(see [3]), but its decision algorithm appears to be quite challenging. As observed in [9], 
bounded polymorphic session types share many properties with the type language in system 
F<: [1]) and subtyping algorithms for extensions of F <: with recursive types are well known 
for their complexity |17} [6]. We leave the decision algorithm for subtyping of behavioral 
types with recursion and bounded polymorphism as future work. 
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ory leak, to Nobuko Yoshida for comments on an early version of this paper, and to the 
anonymous referees for the detailed and useful reviews. 
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Appendix A. Supplement to Section [3] 
Proposition A.l (Proposition 13. The following properties hold: 

(1) T = T. 

(2) lh T implies that T X T and lh T. 

(3) A; {a} lh T and A lh 5 impl y A lh T{ S/a}. 

(4) 0; {a} lh T and lh S imply T{S/a} = T{S/a}. 



TYPING COPYLESS MESSAGE PASSING 



Proof sketch. Item (1) is proved by induction on T. The only interesting case is when 
T = rec a.S. Then, by definition of dual, we have T = rec a.S{{T/a}} and now: 



T = rec a.S{{T/a}}{{T/a}} (by definition of dual) 

= rec a.S{{T/a}} (by definition of inner substitution) 

= rec a.(S{{T/a}}) (because inner substitution and dual commute) 

= rec a.(S{{T/a}}) (by induction hypothesis) 

= rec a.S = T (by folding the recursion) 

Item (2) relies on the fact that duality and unfolding commute. Indeed we have (*) 



rec a.T = rec a.T{{rec a.T/a}} and now: 



T{rec a.T/a} = T{{rec a.T/a}}{rec a.T/a} (def. of inner substitution) 

= T{{rec a.T/a}}{rec a.T/a} (by def. of dual) 

= T{{rec a.T/a}} {rec a.T{{rec a.T /a}} /a} (by (*)) 

= rec a.T{{rec a.T/a}} (by folding the recursion) 

= rec a.T (by (*)) 

In proving items (2-4) it is also needed the fact that A lh T implies ftv(T) C A and 
these free type variables can only occur within prefixes of T. We let the reader fill in the 
remaining details. □ 

Proposition A. 2 (Proposition Let lh T and lh S. Then T < S if and only if 

S <T. 

Proof. It is enough to show that 

^= f s^U{(5,T) |TsCS&0;AlhT&0;AlhS} 

is a coinductive subtyping. Suppose (S,T) G y where (1) T ^ S and (2) 0;A lh T and 
0; A h S. We reason by cases on the shape of T and S: 

• (T = S = end) We conclude immediately since end = end. 

• (T = S = a) This case is impossible because of the hypothesis (2). 

• (T = {?m i (a i )(ti) J T i }i ( z I and S = {?mj{aj)(sj).Sj} j£ j) Then T = {!mi(a i }(ii).r i } ie j and 
S = {\mi(ai)(si).Si}i£j. From (1) we deduce J C J and ij ^ Sj and Tj ^ Si for every 
i G I. From (2) we deduce 0; A, «j lh Tj and 0; A, ai lh S\. By definition of 5? we conclude 
(S~i,Ti) e ^ for every i G /. 

• (T = {!mj(ai)(ii).Tj}j g / and 5 = {\mj(aj)(sj).Sj}j(zj) Dual of the previous case. □ 



Appendix B. Supplement to Section E] 

Before addressing subject reduction and soundness we prove a series of auxiliary results. 
The first one states an expected property of endpoint types, namely that the weight 
where we take the free occurrences of a to have null weight remains finite if we replace 
the same occurrences of a with an arbitrary, but finite-weight endpoint type S (recall that 
T{S/a} is a capture-avoiding substitution). 

Proposition B.l. Let max{||T||{ Q }, ||5||} < oo. Then \\T{S/a}\\ < oo. 
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Proof. We show that {a} h T :: m and S :: n imply T{S/a} :: m + n. It is enough to show- 
that 

W = {(0, T'{S/a},m + n) | 3m € IM : {a} h T' :: m} 
is a coinductive weight bound. Observe that T" :: n implies (0,T",n) € Let (0, T", fe) € 
5^. Then there exist T' and m such that T" = T'{S/a} and k = m+n and (*) {a} \~T' :: m. 
We reason by cases on T' assuming, without loss of generality, that ({a} U ftv(S)) fl 
btv(T') = 0: 

• (T' = end) Trivial. 

• (T' = a) Then T'{S/a} = S and from the hypothesis S :: n we conclude S :: m + n. 

• (T" = j3 ^ a) This case is impossible for it contradicts (*). 

• (T" = {!n i <ai)(t i ).T i } i6 j) Trivial. 

• (T' = {?mi(ai)(qi Si).Ti}i e i) From (*) we deduce m > and {a} h Si :: m — 1 and 
{a} h Tj :: m for every i E I. By definition of 5^ we conclude (0, Si{S/a}, (m— l)+n) G ^ 
and (0, TjlS/a}, m + n) E #^ for every i £ I. □ 

Type variable instantiation does not affect the subtyping relation: 

Proposition B.2. The following properties hold: 

(1) T\ ^ T2 implies T\{S/oi} ^ T2{S/a}; 

(2) ti ^ ti implies t\{S/a} ^ t2{5'/«}- 

Proof sketch. Follows from the fact that a free type variable a can only be related to itself. 
The details are left as an technical exercise. □ 

We now turn to a series of standard auxiliary results of type preservation under struc- 
tural congruence and various forms of substitutions. 

Lemma B.l. Let V h P and P = Q. Then F h Q. 

Proof. By case analysis on the derivation of P = Q. □ 

Lemma B.2 (type substitution). If L;A, a;V h P and lh 5 and \\S\\ < 00, then 
I; A; V{S/a} h P{S/a}. 

Proof sketch. Straightforward induction on the derivation of L; A, a; V h P, using Proposi- 
tions [Bj] and [B^2] wherever necessary. □ 

Lemma B.3 (value substitution). If L; A; V, x : t h P and V + v : s is defined and well 
formed and s ^ t, then I;A;T + v:sh P{v/x}. 

Proof. By induction on the derivation of L; A; F, x : t h P and by cases on the last rule 
applied. We only show the proof of the (T-Send) case, the others being simpler or trivial. 
In the (T-Send) case we have: 

• P = u\m{S)(v).P'; 

• V,x : t = (r",u: q {^(ai)^).^}^/) + v : s"; 
. I;A;r",u:gT ifc {S/a fc }hP'. 

We can assume x € dom(r") U {u} for otherwise x ^ fn(P') and there is nothing left to 
prove. Let V",u : q T^{S/ak} = V',x : t' for some V and t'. In order to apply the induction 
hypothesis and deduce L; A; V + v : s' h P'{v/x}, we must find s' such that (a) s' ^ t' and 
(b) r' + v : s' is defined and well formed. Observe that the type of x, t' , may change from 
the conclusion to the premise of the rule if x = u. We distinguish the following sub-cases: 
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• (v 7^ u, u 7^ x) For (a), we deduce t' = t and we conclude by taking s' = s. For (b), then 
either v dom(T") or un(T"(v)). In both cases we conclude that V + v : s' is defined and 
well formed. 

• (v ^ u, u = x) For (a), we deduce t = q {!mj(ai)(tj).Tj}j g /. From s ^ t, we deduce 
s = q' {\mi{a.i)(si).Si}i£i\jj and q' < q and Si ^ Tj for i E I. By Proposition IB.2f 1) we 
obtain Sk{S/otk} ^ Tk{S/otk} and we conclude by taking s' = Sk{S/ctk}. For (b) we can 
reason as for the previous case. 

• (v = u) Since u € dom(T), then s = V(u) and q = un. Since the un qualifier can only be 
applied to invariant types, it must be the case that Tk{S/otk} = s. We conclude (a) by 
taking s' = s and (b) follows immediately. □ 

Lemma B.4 (weakening). If I; A; V h P and un(P), then I, I'; A, A'; F, H h P. 

Proof. Straightforward induction on the derivation of L; A; V h P. □ 

Lemma B.5 (process substitution). Lei (%) I, {X ^ (A; T)}; A; V h Q. T/ien (%) I, {X 
(A;r)},r;A';r' h P imputes I,Z / ;A / ;r' h P{rec X.Q/X}. 

Proof. By induction on P. Whenever we encounter some bound name/type variable/process 
variable in P we assume, without loss of generality, that it does not occur free in Q: 

• (P = 0) Then P{rec X.Q/X} = 0. From (2) and (T-Idle) we deduce un(r'). We 
conclude with an application of (T-Idle). 

• (P = X) Then P{rec X.Q/X} = rec X.Q. From (2) and (T-Var) we deduce: 

- A' = A, A"; 

- r = r, r"; 

- un(r"). 

From (1) and Lemma EH we obtain Z, {X i-> (A; ?)}, Z'; A'; F' h Q- We conclude with 
an application of (T-Rec). 

• (P = 7 / X) Then P{rec X.Q/X} = Y and we conclude immediately from (T-Var). 

• (P = close(u)) Then P{rec X.Q/X} = close(n) and we conclude immediately from 
(T-Close). 

• (P = P 1 @ P 2 ) Then P{rec X.Q/X} = Pi{rec X.Q/X} P 2 {rec X.Q/X}. From (2) 
and (T-Choice) we deduce: 

- Z, {X ^ (A; T)}, I'; A'; V h P for i = 1,2. 
By induction hypothesis we obtain: 

- Z,Z';A';r' h P{rec X.Q/X} for i = 1,2. 

We conclude with an application of (T-Choice). 

• (P = p 1 | P 2 ) Then P{rec X.Q/X} = Pi{rec X.Q/X} | P 2 {rec X.Q/X}. From (2) and 
(T-Par) we deduce 

- r = Ti + T 2 and 

- Z, {X k> (A; T)}, Z'; A'; r 4 h P for i = 1, 2. 
By induction hypothesis: 

- I,Z';A';ri hP{rec X.Q/X}. 

We conclude with an application of (T-Par) . 

• (P = open(a :T,b: S).P') Then P{rec X.Q/X} = open(a :T,b: 5).(P'{rec X.Q/X}). 
From (2) and (T-Open Linear Channel) we deduce: 

- A' Ih T; 

- Z, {X_^ (A; F)}, T; A'; V , a : lin T, b : lin 5 h P'; 

- S = T. 
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By induction hypothesis: 

- I, I'; A'; r, a : lin T, b : lin 5 h P'{rec X.Q/X}. 

We conclude with an application of (T-Open Linear Channel). 

• (P = open(a : T).P') Similar to the previous case. 

• (P = J2iei u tm(ai)(xi : Si). Pi) Then 

P{rec X.Q/X} = J2^ i {a l )(x i : ii).(P;{rec X.Q/X}). 

tei 

From (2) and (T-Receive) we deduce: 

- r' = r>:lin {?m i (Q i >(s i ).T i } i6 j; 

- JCI; 

- Si ^ ti for every i £ J; 

- (A; T)}, I'; A', af, V',u : lin T;, Xi : t» 1- Pj for every i G J. 
By induction hypothesis: 

- Z,Z / ;A / ,a i ;r / ,it : lin T;,^ : U h P{rec X.Q/X} for i G J. 
We conclude with an application of (T-Receive). 

• (P = u!m(£)(u)..P / ) Then P{rec X.Q/X} = u\m{S)(v).(P' '{rec X.Q/X}). From (2) and 
(T-Send) we deduce: 

- r' = (r'> : (7 {^(oiXtiJ-Ti}^/) + v : s; 

- A' Ih S; 

- m = mfc for some A: G /; 

- s ^ ifc{£/afc}; 

- max{||5||A, ||s||a} < oo; 

- Z, {X ^ (A; T)}, Z'; A'; V" , u : q T k {S/a k } h P' . 
By induction hypothesis: 

- Z, Z'; A'; T", u : lin T'{S/a} h P'{rec X.Q/X}. 
We conclude with an application of (T-Send). 

• (P = rec Y.P') Then P{rec X.Q/X} = rec y.(P'{rec X.Q/X}). From (2) and 
(T-Rec) we deduce: 

- Z, {X -> (A; r), y H- (A'; P')}, Z'; A'; T h P'; 

- (t2) dom(r'|| in ) C fn(P'). 
By induction hypothesis: 

- Z, {Y ^ (A'; T')}, Z'; A'; V h P'{rec X.Q/X}; 
From (t2) and by definition of process substitution: 

- dom(r / || in ) C fn(P') C fn(P'{rec X.Q/X}). 

We conclude with an application of (T-Rec). □ 

The following lemma serves as a slight generalization of subject reduction (Theorem 15. II) . 
Note that the last condition F| un C r'| un implies that unrestricted values can only accumulate 
(they are never removed from the type environment) and furthermore their type does not 
change over time. 

Lemma B.6. Let (1) T ; V R , V h fi where \\n(V R ) and (2) Y h P and (//; P) -> (//; P'). T/ien 
TqJ T^, r' h // and V h P' /or some Fq and F' swc/i i/ia£ r| un C r'| un . 

Proof. By induction on the derivation of (fx; P) — > (//; P') and by cases on the last rule 
applied. 

• (R-Open Linear Channel) In this case: 

- P = open(a :T,b: S).P'; 
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- fjf = fx, a 1-4 [6, e] , 6 \-t [a, e] . 

From the hypothesis (2) and rule (T-Open Linear Channel) we obtain: 

- Ih Tj 

- S = T; 

- !> : lin T,6 : lin T h P' . 

From Proposition 13 . 1 f 1 ) we deduce: 

- W S. 

We conclude by taking Fq = To and V = V,a : lin T, 6 : lin T. The proof that L^; T' h [/,' 
is trivial and F| un = F'| un . 

(R-Open Unrestricted Channel) Similar to the previous case, except that a fresh 
unrestricted pointer is added to V. 
(R-Choice Left/Right) Trivial. 
(R-Send Linear) In this case: 

- P = a\m{S)(v).P'; 

-l-i = i-i",a i-> [6,0], 6 i-> [o,0']; 

- fi' = fj.",a^ [6,0], 6^ [a,0' ::m(5)(v)]. 

From the hypothesis (2) and rule (T-Send) we obtain: 

- (tl) F = (F", a : lin {!m i <a i )(t i ).T i } i6l ) + v : s; 
-QU-S; 

- m = mfc for some k £ I; 

- s ^ ^{S/afc}; 

- US'!! < oo and ||s| < oo; 

- r",a:T fc {%}hP'. 

Let Tq = r + (v : s)|n n and f = (T",a : lin T fc {5/afc}) + (v : s)| un . Since r| un = r'| un we 
only have to show that Vq, Vr, V h fjf. 

We prove the items of Definition 15,21 in order. 

(1) We only need to show that is empty. Suppose by contradiction that this is not 
the case. Then the endpoint type associated with a before the reduction occurs must 
begin with an external choice, which contradicts (tl). 

(2) Let 0' = mi (Ti ) (vi ) :: ••• :: m n (T re )(v n ). From hypothesis (1) and (tl) we deduce 
Vq, Vr, V h b : lin T& and Lb, Vr, V h Vj : Si where 

{?mi(ai)(ti).Ti}i e i = {\mi(ai)(ti).Ti} ie i = tail(T&,mi(Ti)(si) • • • m n (T n )(s n )) 

and by Proposition 13.1( 3) we conclude 

T k {S/a k } = T k {S/a k } = tail(T 6 ,mi(Ti)(si) • ■ ■m n (T n )(s n )m(S)(s)) . 

(3) Immediate from hypothesis (1). 

(4) From hypothesis (1) we have dom(/x) = dom(rb, Vr, F||j n ) and for every a' € dom(/i) 
there exists b' £ dom(F/j, V) such that a' =^ b'. Clearly dom(n') = dom(Fg, Vr, F'|| in ) 
since dom(//) = dom(/i) and don^Lg) U dom(r') = dom(rb) U dom(r). Let 6 bo and 
Vr, P h bo : To and assume v G Pointers. We have v -O 6 =0 6o, namely v =0 bo- 
Now 

||s|| < Utail^^^TiXsi) - - -m„{T„)(s„))|| < ||T 6 || < ||T || 

therefore v ^ bo. We conclude bo € dom(rR, V). 

(5) Immediate from hypothesis (1). 
(R-Send Unrestricted) In this case: 

- P = alm(S)(v).P'] 
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- fi = fi", a H> [a,0]; 

- fi' = fi",a ^ [a, £2 :: m(S)(v)]. 

From the hypothesis (2) and rule (T-Send) we obtain: 

- (tl) r = (r",a : un T) + v : s where T = {!ni(ai)(ti).T} ie i; 

- 0IHS; 

- m = mfc for some k € /; 

- s ^ t fc {5/a fe }; 

- 11511 < oo and ||s| < oo; 

- V",a : unThQ. 

Let Fq = To + (v : s)|| in and V = (V",a : un T) + (v : s)| un . Since r| un = r'| un we only have 
to show that Tq,Yr,T' h //. 

We prove the items of Definition 15.21 in order. 

(1) Trivial since no queue of linear endpoint was affected by the reduction. 

(2) Ditto. 

(3) Let £2 = mi(Ti)(vi) m n (T n )(v n ) and r , V R , V h a : lin T a and T , V R , V h v» : s». 
We deduce 

{?m i (a i )(ii).T} i6/ = {li^MPW = tail(r a ,mi<Ti)(ai) • ■ • m n <T n )(s n )) 
and we conclude 

T = tail(r o ,mi(Ti)(si) • • • m n (T n )(s n )ui(S)(s)) . 

(4) Analogous to the case (R-Send Linear) with T a in place of T&. 

(5) Immediate from hypothesis (1). 
• (R-Receive) In this case: 

- P = Eie/ a?m i( Q i)( x i : U)-Pi\ 

- fi = fi",a (->■ [6,m(5)(v) :: £3] where £2 = mi(5i)(vi) ::•••:: m n (S n )(y n ); 

- m = mfc for some k E I; 

- P' = P k {S/a k }{v/x k }; 

- fi' = fi",a^ [6,0]. 

From the hypothesis (2) and rule (T- Receive) we obtain: 

- r = P',a : lin {?m J (a i )(s l )-7i} ieJ with J C J; 

- Sfe < 

- (t3) a fc ; T", a : lin T k , x k :t k \- P k 

Let To, Vr, rhv:s. From hypothesis (1) and Proposition IB. 21 we obtain: 

- (cl) lh S and ||5|| < oo; 

- (c2) s < s k {S/a k } ^ t k {S/a k }. 
From hypothesis (1) we also deduce that: 

- (fl) if un(s), then v G dom(F) and P h v : s, because all the unrestricted values are in 

r; 

- (f2) if lin(s), then v ^ dom(P), because v a and therefore it must be v £ dom(ro) 
(process isolation prevents a from being reachable from any pointer in dom(TR, V) and 
different from a). 

From (t3), (cl), and Lemma lB.21 we have: 

- (t3') V"{S/a k },a : q T k {S/a k },x k : t k {S/a k } h P k {S/a k }. 

From (fl) and (f2) we deduce that To = Tq,(v : s)||j n for some Vq. Take V = (V",a : 
q T k {S/a k })+v : s and observe that V is well defined by (fl) and (f2) and also r| un C r'| un 
by construction of V. From (t3'), (c2), and Lemma lB.31 we conclude: 
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- V h P k {S/a k }{v/x k } 

We have to show Tg, F/j, V h /i' and we prove the items of Definition 15.21 in order. 

(1) If a = b there is nothing to prove. Suppose a ^ b. Since the queue associated with 
a is not empty in fj,, the queue associated with its peer endpoint b must be empty. 
The reduction does not change the queue associated with b, therefore condition (1) 
of Definition 15.21 is satisfied. 

(2) Suppose a ^ b for otherwise there is nothing to prove. From hypothesis (1) we deduce 
R)) Fr, r h b : lin Tf, and 

T b = taL±l({?m i {a i }(s i ).T i } ieJ ,m(S)(s)m 1 (Si}(s' 1 )---m n (S n )(s' n )) 
= tail(T fc {S'/a fc },nii(S'i}(s / 1 ) • • • m n {S n )(s' n )) 

where Vq, Vr, V h Vj : s[ for 1 < i < n. 

(3) Similar to the previous item, where a = b. 

(4) Straightforward by definition of Tq and V. 

(5) Immediate from hypothesis (1). 

• (R-Par) In this case: 

- P = P 1 \P 2 ; 

- Ojl-P^^^'-PD; 

- P' = P{ | P 2 . 

From the hypothesis (2) and rule (T-Par) we obtain: 

- r = T x + r 2; 

- r, h P t for i G {1, 2}. 

In particular, from Lemma IB. 41 we have: 

- (To! ^R, 1~2 1 lin , Tl) + f^lun ^ (1>\ 

- ri + r 2 | un \-Pl- 

By induction hypothesis we deduce that there exist Fq and V[ such that: 

- (Ti + r2| un )|un = (Fl + F 2 )| un ^ Hllun! 

- To; r#, r 2 1 lin , 1 1~ m'; 

- n h p{. 

Now r 2 1 1 i n , r{ = 1^2 1 1 J n , ( F{ + T 2 | un ) = V[ + Y 2 - Therefore, from rule (T-Par) we obtain 
r{ + T 2 h P'. We conclude by taking V = V[ + F 2 . 

• (R-Rec) In this case: 

- P = rec XQ; 

- P' = Q{P/X}; 

- n' = A»- 

From the hypothesis (2) and rule (T-Rec) we obtain: 

- (t3) {X^(0;r)};0;rhQ; 

- dom(r|| in ) C fn(Q). 

From (t3) and Lemma lB.5l we obtain: 

- r h P'. 

We conclude by taking Fq = r and f = F. 

• (R-Struct) Follows from Lemma IB. II and induction. □ 

We conclude with the proofs of subject reduction and soundness. 

Theorem B.l (Theorem EH). Let F ; F h (//; P) and 0;P) -> (//;P')- T/ieri r o5 r ' H 
(/i';P') /or some Fq and V. 

Proof. Follows from Lemma lB.61 by taking Fr = 0. □ 
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Proposition B.3. Let V h P. Then fn(P) C dom(r) and dom(rj| in ) C fn(P). 

Proof. Prom the hypothesis T h P we deduce that P is closed with respect to process 
variables. The results follows by a straightforward induction on the derivation of V h P and 
by cases on the last rule applied, where the case for (T-Var) is impossible by hypothesis 
and (T-Rec) is a base case when proving the second inclusion. □ 

Theorem B.2 (Theorem 15. 2|) . Let h P. Then P is well behaved. 

Proof. Consider a derivation (0;P) (fi;Q). Prom Theorem 15.11 we deduce (*) lb; V h 
(fi;Q) for some Hd and F. We prove conditions (1-3) of Definition 14.21 in order: 

(1) Using Proposition IB.31 Definition 14.11 and Definition 15.21 we have reach(f n(Q), /i) C 
reach(dom(r), /x) = dom(/x) and dom(/x) = reach(dom(r), /i) = reach(dom(r||j n ), /i) C 
reach(f n(Q), fj). 

(2) Suppose Q = P\ | P2. By Lemma IB. II we deduce V h Pi | P2, namely there exist Fi 
and I2 such that F = Ti + F2 and Fj h P». From the definition of r\ + F2 we deduce 
dom(Fi||j n ) fl dom(F2||j n ) = 0. From Proposition IB.3I we have fn(Pj) C dom(Fj) for i G 
{1,2}. From (*) we conclude reach(fn(Pi), /i)nreach(f n(P2), fl) C reach(dom(Fi), /x)n 
reach(dom(r2), /i) = reach(dom(ri || in ), /j) fl reach(dom(r2|ii n ), fi) =0. 

(3) Suppose Q = P' I Q' where P' has no unguarded parallel composition and (fJ,;Q) -ft. 
Then P' contains no unfolded recursion, choice, open, output prefix that is not guarded 
by an input prefix, for all these processes reduce. In the case of output prefixes, one uses 
r ; r h fx to deduce that either (R-Send Linear) or (R-Send Unrestricted) can be 
applied. Suppose P' ^ 0. Then either P' = close(a) or P' = J2i^i a ^ m i( a i)i x i '■ U)-Pi- 
Suppose by contradiction that the queue associated with a is not empty, namely that 
a 1 y [b, m(5)(v) :: 0] G fx. From the hypothesis T h /i we deduce that the endpoint type 
associated with a cannot be end, and therefore P' 7^ close(a). From the hypothesis 
r h Q and rule (T-Receive) we deduce F h a : lin {?mj(aj)(sj).Tj}j e j and J C I. From 
the hypothesis r h /1 we deduce m = for some k G J, namely (/x; P') — >•, which is 
absurd. □ 



Appendix C. Supplement to Section 

C.l. Subtyping. In order to prove correctness and completeness of the sub typing algo- 
rithm (Definition I6.2p with respect to the subtyping relation (Definition I3.2p we need a few 
more concepts. The first one is that of trees of an endpoint type T, which is the set of 
all subtrees of T where recursive terms have been infinitely unfolded. We build this set 
inductively, as follows: 

Definition C.l (endpoint type trees). We write trees(T) for the least set such that: 

• T G trees(T); 

• rec a.S G trees(T) implies S{zec a.S/a} G trees(T); 

• {fmj(aj)((/j Si).Ti}i € [ G trees(T) where f G {?, !} implies Si G trees(T) and Tj G 
trees(T) for every % G I. 

Observe that trees(T) is finite for every T, because the infinite unfolding of an endpoint 
type is a regular tree [7j. Also, every free type variable in S G trees(T) is either free in T 
or it is bound by a prefix of T. In particular, it cannot be bound by a recursion. 
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The next concept we need is that of instance of an endpoint type subtree. The idea is 
to generate the set of all instances of the (trees of the) endpoint types that the subtyping 
algorithm visits, and to make sure that this set is finite. Looking at the rules in Table [TU1 we 
see that only type variables that are bound in a prefix m(a)(t) are ever instantiated. Also, 
each variable a in one of the endpoint types can be instantiated with ir\(a,f5) where j3 is 
some type variable of the other endpoint type. These considerations lead to the following 
definition of endpoint type instances: 

Definition C.2 (endpoint type instances). Let m be a map as by Definition 16.21 We define 
instances(m, T, S) as the smallest set such that: 

• if T' e trees(T) and {oi,...,a ri } = f tv(T') n btv(T) and {ft, . . . , /3 n } C btv(5), then 
T'{m(ai,/3i)/ai} • • • {m(a n , P n )/a n } G instances(m, T, S); 

• if S' € trees(S) and . . . , f3 n } = ftv(S') n btv(S) and {ai, . . . , a n } C btv(T), then 
5'{m(/3i,ai)//3i} • • • {m(/3 n , a n )/0 n } € instances(m, T, 5). 

Observe that T, 5 € instances(m, T, 5*) and that instances(m, T, S 1 ) is finite, since it 
contains finitely many instantiations of finitely many subtrees of T and S. 

Proposition C.l. Every endpoint type occurring in the derivation of h m T ^ a S is in 
instances(T, S). 

Proof sketch. A simple induction on the derivation of h m T ^ a S. □ 

Lemma C.l. Let h m T ^ a S and {(T, S)} h m T ^ a S' . Then h m V s^ a S' . 

Proof sketch. A simple induction on the proof of {(T, S)} h m T' ^ a S' where every applica- 
tion of rule (S- Axiom) for the pair (T, S) is replaced by a copy of the proof of b m T ^ a S. 

□ 

Theorem C.l (Theorem 16. ID . Let To and So be independent endpoint types and m be a 
map as by Definition \6.!$ . Then h m To ^ a So if and only if To ^ Sq. 

Proof. (=>■) It is enough to show that 

y dgf S) | h m T ^ a S 1 & T, S G instances(m, T , 5 )} 

U {(g T,q' S) \ q < q' &T,S £ instances(m, T , 5 ) & h m T sj a S} 

is a coinductive subtyping. Let (q T, 5) € S fi . Then q < q' and h m T ^ a 5. By 
definition of J? we conclude (T, 5) E 

Let (T, 5) £ =y. Then (J) h m T ^ a S. We reason by induction on the num- 
ber of topmost applications of rules (S-Rec Left) and (S-Rec Right) (which must be 
finite because of contractivity of endpoint types) and by cases on the first (bottom-up) 
rule different from (S-Rec Left) and (S-Rec Right) applied for deriving (J), observing 
that is cannot be (S- Axiom) for the context is initially empty and rules (S-Rec Left) 
and (S-Rec Right) only add pairs of endpoint types where at least one of them begins 
with a recursion: 

• (S-Rec Left) Then T = rec a.T and {(T,S)} h m T'{T/a} ^ a S. From (J) and 
Lemma fC.ll we derive h m T'{T/a} ^ a S. By induction hypothesis we derive T'{T/q} ^ 
S and we conclude by observing that T = T'{T/a}. 

• (S-Rec Right) Symmetric of the previous case. 

• (S-Var) Then T = S = a and there is nothing left to prove. 

• (S-End) Then T = S = end and there is nothing left to prove. 
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• (S-Input) Then T = {7w i (an)(U).Ti}iei and S = {^{^{s^.S^^j . Let 7i = 
m(aj,/3j) for i G /. From (S-Input) we deduce: 

- {(T, S)} h m ti{7i/ai} ^ a Si{7i/ft} for every % G I; 

- {(T, S)} h m T^ i/oii} ^ a Si{>ji/f3i} for every z G /. 
From Lemma IC. II we derive: 

- H m tj{7i/ai} < a s.j{7i//3i} for every i G /; 

- T^/a,} ^ a S , i{ 7 i/A} for every i G /. 

By definition of y we know that T, S" G instances(m, To, So). For every z G /, we can 
deduce that 7 j f tv(tj) U ftv(T) U ftv(sj) U ftv(S'j), because 7 j can only substitute the 
free occurrences of ai and of Pi and: 

- aj is bound in the i-th branch of T and does not occur in S; 

- (3i is bound in the i-th branch of S and does not occur in T. 
Therefore, by alpha conversion we obtain: 

- T = {?m i ('y i )(t i {'yi/ai}).Ti{'yi/ai}}i e i; 

- S = {?m i (7i)(si{7 i /ft}).5i{7i/ft}} ie / + {?m j (^-)(sj)-S'i}jeJ\/- 

We conclude (a<{7i/A},<i{7i/ft}) 6 ^ and (SiH/PihTiH/Pi}) e ^ by definition of 

y. 

• (S-Output) Analogous to the previous case. 

(-4=) We prove that T, S G instances(m, To, So) and T ^ S imply y h m T ^ a S by 
induction on instances(m, T, S)\y. In the base case we have (T, 5) G y and we conclude 
with an application of (T- Axiom). For the inductive case we reason by case analysis on 
the structure of T and S, knowing that T ^ S: 

• (T = S = a) We conclude with an application of (S-Var). 

• (T = S = end) We conclude with an application of (S-End). 

• (T = rec a.T') Since T = T'{T/a} we have T'{T/a} ^ S. By induction hypothesis we 
know that yu {(T, 5)} h m T'{T/a} ^ a 5* is derivable. We conclude with an application 
of (S-Rec Left). 

• (S = rec a.S') Symmetric of the previous case. 

. (T = {?m i {a l )(q l T/).^}^ and 5 = {1m j (fi j )(g , i S^.S^j and I Q J) From the hy- 
pothesis T ^ S we know that for every i £ I there exists 7, such that qi < q\ and 
T/{7i/aj} < S-i-fi/Pi} and T{ 7i /aj} < S^i/A}. Since T, 5 G instances(m, T , So) 
we know that <5j = m(a i ,/3 i ) g" ftv(T/) U ftv(T) U ftv(S-) U ftv(Si). We deduce 
T/{<5i/ai} < S'^Si/Pi} and T^^/aJ < Sj{<5j//3j} for every iel. By induction hypoth- 
esis we derive that & U {(T, 5)} h m T/ ^ a 5",' and y U {(T, S 1 )} h m T # are derivable 
for every i G T Also, ^ U {(T, 5)} h m qi T[ ^ a <?i S\ is derivable with an application of 
(S-Type) for every i G I. We conclude y h m T < a £ with an application of (S-Input). 

• (T = {!mj(o!j)(ti).Tj}i e / and 5 = {!m J (/3j)(,Sj).S'.,}., e j and J C I) Analogous to the previ- 
ous case. □ 

C.2. Type Weight. We begin by proving that the weight algorithm is unaffected by fold- 
ings/unfoldings of recursive terms. 

Proposition C.2 (Proposition WM- W(A o ,0,rec a.T) = W(A , 0, T{rec a.T/a}). 

Proof. Let W(Ao,0,rec a.T) = w. We prove a more general statement, namely that for 

every S and A such that W(Ao, A, S) < w and btv(5) n ftv(T) = we have: 

(1) a G A implies W(A , A, S) < W(A , A \ {a}, 5{rec a.T/a}) < max{t«, W(A , A, S)}; 
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(2) a & A implies W(A , A, S) = W(A , A \ {a}, S{rec a.T/a}). 

The statement then follows from (1) by taking S = T and A = {a} and noting that 
W(Ao,0,rec a.T) = W(Ao,{a},T) by definition of algorithmic weight. We proceed by in- 
duction on S assuming, without loss of generality, that ({a} U f tv(T)) n btv(<S) = 0: 

• (S = end or S = {\mi{ai)(ti)Ti} ieI ) Clear as W(A , A, S) = W(A , A\{a}, ^{rec a.T/a}) = 
0. 

• (S = a) We have W(A , A \ {a}, S{rec a.T/a}) = W(A , A \ {a}, rec a.T) = w therefore 
we conclude: 

(1) W(A , A, S) = < w = W(A , A \ {a}, S{rec a.T/a}) = m&x{w, W(A , A, S)}; 

(2) W(A , A, S) = oo = w = W(A , A \ {a}, S{rec a.T/a}). 

• (S = /3 / a) Trivial since W(A , A, S) = W(A , A \ {a}, S{rec a.T/a}). 

• (S = rec (3.S 1 ) By induction hypothesis we deduce: 

(1) a G A implies 

W(A ,AU{/3},5') < W(A ,(AU{/3})\{a},5'{rec a.T/a}) < max{w,W(A , AU{/3}, 5')}; 

(2) a A implies W(A , A U {/?}, S') = W(A , (A U {/3}) \ {a}, S'{rec a.T/a}). 
We conclude by definition of algorithmic weight, since: 

- W(A , A, S) = W(A , A, rec (3.S') = W(A , A U {/3}, S'), and 

- W(A ,A\ {a},5{rec a.T/a}) = W(A , A \ {a}, (rec (3.S'){rec a.T/a}) = W(A ,A\ 
{a}, rec (3.(S'{rec a.T/a})) = W(A , (A U {/?}) \ {a}, S'{rec a.T/a}). 

• (S = {?mi(ai)(ti).Ti}i € [) By induction hypothesis on ti and T, for j £ / we deduce: 

(1) W(A , 0, U) = W(A , 0, ti{rec a.T/a}); 

(2) a £ A implies 

W(A , A \ {ai}, TO < W(A , A \ {a u a}, T^rec a.T/a}) < max{ W , W(A , A \ {aj, T)}; 

(3) a A implies W(A , A \ {a j, Tj) = W(A , A \ {a { , a}, T^rec a.T/a}). 
If a £ A we conclude: 

W(A , A, S) = max{l + W(A , 0, U), W(A , A \ {a^}, Ti)} ie / 

= max{l + W(A o ,0,t i {rec a.T/a}), W(A , A \ {aj, Tj} ieI 

< max{l + W(A o ,0,ti{rec a.T/a}), W(A , A \ {a i; a}, T,{rec a.T/a})} ieI 
= W(A , A \ {a}, 5{rec a.T/a}) 

< max{l + W(A , 0, U{rec a.T/a}), w, W(A , A \ {aj, T)} ie/ 
= max{l + W(A , 0, U),w, W(A , A \ {a^}, T)} ie / 

= max{w, W(Ao, A, 5)} 

If a A we conclude: 

W(A , A, S) = max{l + W(A , 0, U), W(A , A \ {a^}, T)} l£ / 

= max{l + W(A o ,0,tj{rec a.T/a}), W(A , A \ {aj, a}, T{rec a.T/a})} ie / 
= W(A , A \ {a}, 5{rec a.T/a}) . 

□ 

The next lemma states that, if the weight algorithm determines a weight n for some endpoint 
type T, then n is a weight bound for T. 

Lemma C.2. 7/W(A,0,T) = n <E N, i/ien A h T :: n. 

Proof. It is enough to show that 

d = {(A, T, n) | W(A, 0, T) < n € N} 
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is a coinductive weight bound. Let (A,T,n) G W. Then (h) W(A,0,T) < n G N. Without 
loss of generality we may assume that T does no£ begin with a recursion. If this were not 
the case, by contractivity of endpoint types we have T = T' where T' does not begin with 
a recursion. Now, by Proposition 16.21 we deduce W(A, 0, T') = W(A,0,T) = n and therefore 
(A, T", n) G W by definition of W. 
We reason by cases on T: 

• (T = end or T = {\mi(aci)(ti).Ti}i e i) There is nothing to prove. 

• (T = a) From (h) we deduce a G A and there nothing left to prove. 

• (T = {?m i ( Q ! i )(gi Si).Ti} ieI ) Then < W(A,0,T) < n. From (h) we deduce W(A,0,5 , i ) < 
n-1 and W(A, 0, Tj) < n for every i G I. We conclude (A, Si,n-1) G W and (A, T h n) G /T 
for every j 6 J. □ 

The last auxiliary result proves that the weight algorithm computes the least upper weight 
bound for an endpoint type. We use a to range over arbitrary substitutions of endpoint 
types in place of type variables, we write Ta for T where the substitutions in a have been 
applied, and dom(cr) for the domain of a (the set of type variables that are instantiated). 

Lemma C.3. If A h Ta :: n, then W(A, dom(cj), T) < n. 

Proof. By induction on T: 

• (T = end or T = {Im^aj)^).^}^/) Easy since W(A, dom(cr), T) = 0. 

• (T = a) From the hypothesis A h Ta :: n we deduce a G A U dom(cj). By definition of 
algorithmic weight we conclude W(A, dom(cj), T) = 0. 

• (T = rec a.S) Let a 1 = (cr\a), {a i— > T} where <r\a is the restriction of a to dom(o")\{a}. 
We have A h So' :: n. By induction hypothesis we deduce W(A, dom(o") U {a}, S) < n. By 
definition of algorithmic weight we conclude W(A, dom(cr), T) = W(A, dom(cr), rec a. S) = 
W(A,dom(cr) U {a}, S) < n. 

• (T = {?mi{ai)(qi Si).Ti}i<=i) For every i G / let crj = a \ {aj}. From the hypothesis 
A h Ta :: n we deduce A h SiO~i :: n — 1 and A h T{Oi :: n for every % G By induction 
hypothesis we deduce W(A, dom(o"i), <%) < n — 1 and W(A, dom(cjj), Tj) < n. We conclude 
W(A, dom(cr), T) < n by definition of algorithmic weight. □ 

Correctness of the weight algorithm is simply a combination of the two previous lemmas. 

Theorem C.2 (TheoremES}. ||T|| A = W(A, 0, T). 

Proof. From Lemma IC.2I we deduce ||T||a = min{n G N | A h T :: n} < W(A, 0,T). From 
Lemma fC. 3j by taking a = (the empty substitution), we conclude W(A, 0,T) < ||T||a- D 
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